Context-aware output encoding
Output encoding represents untrusted text safely for the context where it is displayed.
What it means
Output encoding represents untrusted text safely for the context where it is displayed. HTML text, HTML attributes, JavaScript, and URLs follow different parsing rules. An encoder suitable for one context may leave another context exposed. Prefer framework rendering that handles plain text automatically.
A practical example
A support dashboard displays a customer-supplied message as text instead of interpreting it as markup. The same message is not inserted into an inline script or used as an unrestricted link destination. These locations require separate decisions.
What to check
Trace each user-controlled value to its final rendering location. Use maintained context-specific encoders, quote attributes, avoid dangerous sinks, and test the actual browser output.
A common pitfall
Encoding everything once when data enters the database can cause double encoding and still miss the final context. The destination determines the required protection.
Think it through
Can HTML escaping make an arbitrary URL safe to navigate?
Answer: No. URL schemes and destinations need validation; HTML encoding only protects the surrounding markup context.
The destination determines interpretation
Suppose a fictional helpdesk shows a ticket title as page text, uses it in an HTML attribute, and includes it in a downloadable report. The title is one stored value, but each destination has its own syntax. The application should keep the value as data and apply the appropriate handling when it reaches each destination. Encoding it once at storage time hides those differences.
Some destinations should be avoided rather than made more complicated. An untrusted value inserted into executable JavaScript or an unsafe HTML API creates a more difficult contract than ordinary text rendering. Moving the value into a data property or using a safe text API can remove an entire parsing problem. Framework auto-escaping is helpful only when developers stay within the framework's supported safe patterns.
Nested contexts require particular care. A URL placed inside an HTML attribute involves both URL semantics and HTML syntax. Escaping the quote characters around the attribute does not decide whether the destination is appropriate. Keep scheme validation, destination policy, and markup encoding as distinct steps so reviewers can explain each guarantee.
Inspect the rendered result
In a local exercise, display a harmless ticket title containing an ampersand, quotation marks, and angle brackets. Check the visible page and inspect the resulting DOM. Then compare plain text with intentionally supported rich text, which needs a different design. Avoid treating a screenshot alone as proof that the underlying markup is safe.
When reviewing a finding, trace how the value is transformed on the way to the final sink. Repeated encoding may produce broken display without solving the relevant parser issue. A useful repair identifies the destination, chooses a supported rendering primitive, and adds a regression example that preserves legitimate punctuation. This keeps both security and ordinary language support intact.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Cross Site Scripting Prevention