Production engineering
using System;
using System.Linq;
using System.Collections.Generic;
using System.Globalization;
using System.Text;
using System.Text.Json;
using System.Threading;
using System.Threading.Tasks;
string encoded=System.Text.Encodings.Web.HtmlEncoder.Default.Encode("<b>rune</b>"); Console.WriteLine(encoded); Console.WriteLine("raw markup:"+encoded.Contains("<b>",StringComparison.Ordinal)); var uri=new Uri("javascript:alert(1)"); Console.WriteLine("https allowed:"+(uri.Scheme=="https"));
Reveal answer and reasoning
The output lines, in order, are “<b>rune</b>”; “raw markup:False”; “https allowed:False”. The portable .NET9 console program calls the actual BCL HtmlEncoder for a supplied bold-tag string. It prints <b>rune</b> and then raw markup:False because the encoded result does not contain the original opening tag. It separately constructs a javascript URI and compares its scheme with https, printing https allowed:False. That scheme decision is an application policy, not an effect of HTML encoding.
No browser renders the value and no network request is sent to the URI. The output demonstrates two independent transformations or decisions rather than combining them into one ambiguous security assertion.
Encoding is not a replacement for validating a URL's allowed scheme, authenticating a caller or authorizing access to data. It also does not add a Content Security Policy or prove that downstream code never decodes and reinserts text into a dangerous context. A future change from paragraph text to script content needs an independent design rather than reusing a previously encoded value.
Storing encoded text as a universal representation can additionally produce double encoding or make later contexts harder to reason about. Preserve original data where appropriate and encode at the actual output boundary with the intended context visible.
What a strong answer covers
- Exact output: <b>rune</b> | raw markup:False | https allowed:False
- The portable .NET9 console program calls the actual BCL HtmlEncoder for a supplied bold-tag string.
- Encoding is not a replacement for validating a URL's allowed scheme, authenticating a caller or authorizing access to data.
Common pitfall
Encoding is not a replacement for validating a URL's allowed scheme, authenticating a caller or authorizing access to data. It also does not add a Content Security Policy or prove that downstream code never decodes and reinserts text into a dangerous context. A future change from paragraph text to script content needs an independent design rather than reusing a previously encoded value. Storing encoded text as a universal representation can additionally produce double encoding or make later contexts harder to reason about. Preserve original data where appropriate and encode at the actual output boundary with the intended context visible.
Follow-up questions
- Why would checking that the entire HTML document contains no angle brackets be an incorrect test of this endpoint?
- How can pre-encoding stored text lead to double encoding when a later view encodes it again?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.