Security isn't a feature you bolt on at the end — it's a set of constraints woven into every layer. This page lets you analyze headers, test XSS payloads safely, and simulate CORS negotiations. Every tool below uses real logic, not mockups.
| Header | Purpose | Recommended | Status |
|---|---|---|---|
| Content-Security-Policy | Controls which resources the browser is allowed to load. The single most effective defense against XSS — it allowlists script sources, blocking injected scripts even if they reach the DOM. | default-src 'self'; script-src 'self' | ✓ |
| Strict-Transport-Security | Forces browsers to connect only over HTTPS for a specified duration. Prevents protocol downgrade attacks and cookie hijacking over HTTP. | max-age=63072000; includeSubDomains; preload | ✓ |
| X-Content-Type-Options | Prevents MIME-type sniffing. Without it, browsers may reinterpret a file's type, potentially executing a CSS file as JavaScript. | nosniff | ✓ |
| X-Frame-Options | Prevents your page from being embedded in an iframe on another origin. Blocks clickjacking attacks where a malicious site overlays your UI. | DENY | ✓ |
| Referrer-Policy | Controls how much URL information is sent in the Referer header when navigating away. Balances analytics needs with user privacy. | strict-origin-when-cross-origin | ✓ |
| Permissions-Policy | Controls which browser features (camera, microphone, geolocation, payment) the page and its iframes can access. Limits the attack surface of embedded content. | camera=(), microphone=(), geolocation=() | ✓ |
| X-XSS-Protection | Legacy header that activated the browser's built-in XSS filter. Modern browsers have removed this filter because it introduced its own vulnerabilities. Now recommended to set to 0 to explicitly disable, or omit entirely. |
0 | ⚠ deprecated |
Why the left side is dangerous: Inserting user input as innerHTML allows the browser to parse and execute any HTML, including event handlers like onerror, onmouseover, and injected <style> blocks. The <script> tag doesn't execute via innerHTML (a browser safety measure), but event-based payloads do.
Why the right side is safe: Escaping replaces < with <, > with >, and " with " — the browser renders them as visible text, never as executable markup. This is called output encoding and is the primary defense against stored and reflected XSS.
Defense-in-depth at the HTTP layer. Headers like Content-Security-Policy, Strict-Transport-Security, and X-Frame-Options form a perimeter that mitigates entire categories of attacks — even when application code has vulnerabilities.
The XSS demo shows the fundamental principle: never trust user input. Escaping output (< for <) renders payloads as visible text instead of executable code. This is the single most important XSS defense.
Cross-Origin Resource Sharing isn't a wall — it's a protocol the browser enforces. The simulator shows how Access-Control-Allow-Origin headers, preflight requests, and credential handling interact to control cross-origin access.
CSP is the most powerful security header. A strict policy like script-src 'self' blocks all inline scripts and scripts from other domains — even if an attacker manages to inject HTML into the page, the scripts won't execute.
No single control prevents all attacks. Security headers protect the transport layer. Output encoding protects the rendering layer. CSP protects the execution layer. CORS protects the data layer. Layered defenses mean a failure in one doesn't compromise the system.
This layer is supported by two freeCodeCamp Information Security certifications covering HelmetJS, pen-testing with Python, TCP/IP fundamentals, cryptography, and network security — 600+ hours of structured security training.