PENTESYS POINT OF VIEW · ENGINEERING · 4 min read
Part of Validate insights →XSS prevention across rendering and content workflows
Choose controls for the actual browser output context and check stored client-side and rich-content paths.
Keep untrusted content from becoming executable browser behaviour; a single escaping function cannot be assumed to suit every context.
Map where the browser receives untrusted content
Follow the information from its source through storage, transformation and rendering. A customer name, support note, imported record or URL fragment may reach several browser contexts. Identify whether it becomes ordinary text, an attribute, a URL, script-related data or rich HTML. The relevant control depends on that output path, not only on the form where the value first entered the system.
Prefer safe rendering by default
Use the framework's safe text-rendering behaviour and appropriate output handling for the intended context. Avoid unnecessary raw-HTML features and dangerous DOM operations. A framework can provide a useful default without protecting code that deliberately bypasses it. Review components, templates and client-side updates together so a safe initial response is not undermined by a later browser-side transformation.
Define the rich-content boundary
Where a feature intentionally accepts HTML, use a maintained sanitisation approach with a policy that matches the business need. Preserve the distinction between permitted formatting and executable behaviour. Check what later transformations do to the sanitised result. Do not assume a value that was safe for one display context remains safe after being inserted into another component or reconstructed by client code.
Use defence in depth without confusing its role
A suitable Content Security Policy can constrain some consequences, but it does not remove the need for safe rendering and context-aware handling. Keep important dependencies current and review application features that expand browser execution or content loading. Treat a browser control as one layer in the design rather than using its presence to close an unresolved unsafe rendering path.
Verify the complete workflow
Use authorised controlled records to check the original path and related displays, including administrative views, exports rendered in a browser and client-side updates. Confirm allowed formatting and legitimate content still work. Record the affected context and application version, and add regression tests at the appropriate rendering boundary. The useful closure evidence explains why untrusted data stays data throughout the relevant workflow.
Turn the analysis into action.
- Identify the actual browser contexts for each untrusted value.
- Use safe rendering and an explicit rich-content policy.
- Check related displays and retain regression evidence.
Sources and further guidance
Use the essential guide for the wider scope, process and buying context behind this analysis.
Read “Penetration testing: scope, process, costs and what happens after the report” →This current engineering guide replaces the retired legacy topic. Apply the recommendations to the actual application and verify changes within an authorised scope.
