Cross-site scripting protection.
Detect and resist XSS injection and sanitize untrusted data wherever it lands — emails, API payloads, and both front-end and back-end rendering — by encoding for the output context so a value meant as text is never parsed as markup.
1. The threat: your page as the delivery vehicle
Cross-site scripting turns your own application into the attacker’s script-delivery mechanism. When untrusted input is reflected into a response without being treated as data, the browser parses it as markup and executes it in your origin — with full access to cookies, the DOM, and your authenticated APIs. XSS persists on the OWASP Top 10 because every surface that renders user input is a candidate: stored (persisted and replayed to every viewer), reflected (echoed from the request), and DOM-based (assembled entirely in the browser, where the server never sees it).
2. The principle: encode for the output context
Blocklists of “dangerous” strings lose to an attacker’s endless encodings. The durable defense is to contextually encode on output and validate on input, so the same value is rendered safely whether it lands in HTML body, an HTML attribute, a URL, or a block of JavaScript. Each of those is a different grammar with a different encoder; choosing the right one is what closes attribute break-out and script-context injection.
3. Everywhere untrusted data lands
XSS is not only a web-page problem. The same untrusted value flows into transactional emails, into API responses consumed by other systems, into logs, and into server-side rendering. B5 Secure applies sanitization and context-appropriate encoding across all of these surfaces — front-end and back-end, HTML and non-HTML — so a value cannot slip through one channel because the defense was wired only into another.
4. How B5 Secure handles it
B5 Secure folds XSS defense into the request pipeline rather than leaving it to each controller. Untrusted input is validated and encoded for its destination context as a property of the framework, consistent with the “Never Trust” default: input is hostile until proven otherwise, and it is rendered as text unless something explicitly and safely says otherwise. For the developer-facing detail, see the companion articles on XSS by example and defending XSS in ASP.NET.