Give each browser defense its own job

First, build a mental model

Follow untrusted data and ambient authority. XSS turns data into executable content; CSRF abuses a browser's automatically attached credentials; CORS controls which origins can read eligible cross-origin responses.

1. For plain text, use safe text rendering such as textContent. For rich HTML, use a maintained sanitizer suitable for the context; do not invent a regular-expression sanitizer.
2. Cookie-authenticated state changes need appropriate CSRF defenses, including verified origin/token strategies and suitable cookie attributes. SameSite is useful defense in depth, not a universal replacement for the full design.
3. CORS is a browser response-sharing policy. It does not stop all requests, non-browser clients or unauthorized server operations.
4. CSP narrows allowed content/resource execution and is defense in depth. Secrets must stay out of shipped bundles, source maps, logs and fixtures; a variable name containing SECRET does not protect a value.

const message = document.createElement('p');
const untrustedName = '<strong>Alice</strong>';
message.textContent = untrustedName;
// Displays the characters; it does not parse markup.
// Do not replace this with innerHTML for plain text.

1. Input

   A name contains markup-like text that the application does not trust.

2. Safe sink

   textContent assigns a text value rather than invoking HTML parsing.

3. Separate controls

   Server authorization, CSRF defenses and CSP still need their own design; one safe text assignment does not prove the whole app secure.