Calling get on a std::unique_ptr object returns a pointer to the underlying allocations.
+When the std::unique_ptr object is destroyed, the pointer returned by get is no
+longer valid. If the pointer is used after the std::unique_ptr object is destroyed, then the behavior is undefined.
+
+Ensure that the pointer returned by get does not outlive the underlying std::unique_ptr object.
+
+The following example gets a std::unique_ptr object, and then converts the resulting unique pointer to a
+pointer using get so that it can be passed to the work function.
+
+However, the std::unique_ptr object is destroyed as soon as the call
+to get returns. This means that work is given a pointer to invalid memory.
+
+The following example fixes the above code by ensuring that the pointer returned by the call to get does
+not outlive the underlying std::unique_ptr objects. This ensures that the pointer passed to work
+points to valid memory.
+
To guard against cross-site scripting, consider using contextual output encoding/escaping before -writing user input to the page, or one of the other solutions that are mentioned in the -references.
+
+To guard against cross-site scripting, consider using a library that provides suitable encoding
+functionality, such as the System.Net.WebUtility class, to sanitize the untrusted input before writing it to the page.
+For other possible solutions, see the references.
+
The following example shows the page parameter being written directly to the server error page, -leaving the website vulnerable to cross-site scripting.
- -+The following example shows the page parameter being written directly to the server error page, +leaving the website vulnerable to cross-site scripting. +
+
+Sanitizing the user-controlled data using the WebUtility.HtmlEncode method prevents the vulnerability:
+