Security Best Practices

Older guidance recommended enabling the browser's built-in X-XSS-Protection filter. Modern browsers have actually removed this feature — Chrome dropped it in 2019, and it's no longer a meaningful defense in any current browser, since the heuristic filter it powered had its own exploitable bugs and was replaced by better mechanisms. Content Security Policy is what actually stops injected scripts from executing today:

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.headers(headers -> headers
        .contentSecurityPolicy(csp -> csp
            .policyDirectives("default-src 'self'; script-src 'self'")
        )
    );
    return http.build();
}

With script-src 'self', even a successfully injected <script> tag simply won't execute — the browser refuses to run inline or externally-hosted scripts that violate the policy, regardless of whether the escaping above was somehow bypassed. Treat CSP as the defense-in-depth layer, not output escaping as the only layer.

NIST SP 800-63B — the current US federal digital identity guideline, and the reference point most modern security teams follow — explicitly recommends against mandatory composition rules like "must contain an uppercase letter and a digit." In practice, these rules produce a small, predictable set of user behaviors — Password1!, appending 123 to a familiar word — that add negligible real entropy while measurably increasing how often users write passwords down or reuse a slightly modified pattern across sites. The current guidance instead favors: a generous minimum length (12+ characters), no forced periodic rotation without evidence of compromise, and — the check that actually matters — screening new passwords against a database of known-breached passwords.

// OUTDATED — composition rules NIST now recommends against
public void validatePassword(String password) {
    if (password.length() < 8) {
        throw new ValidationException("Password must be at least 8 characters");
    }
    if (!password.matches(".*[A-Z].*")) {
        throw new ValidationException("Password must contain uppercase letter");
    }
    // This rule set is exactly what pushes users toward "Password1!"
}

// CURRENT GUIDANCE — length and breach screening, not composition rules
public void validatePassword(String password) {
    if (password.length() < 12) {
        throw new ValidationException("Password must be at least 12 characters");
    }
    if (breachedPasswordChecker.isKnownBreached(password)) {
        throw new ValidationException("This password has appeared in a known data breach — choose another");
    }
    // No forced uppercase/digit/symbol composition requirement
}

Q: Your team enforces a strict password composition policy (uppercase, digit, special character, 8-char minimum) and considers this strong security. Explain why current guidance argues this is actually weaker than a simpler length-based policy.
Composition rules constrain the space of passwords users are willing to remember far more than they constrain the space an attacker has to guess — faced with "must contain an uppercase letter and a digit," the overwhelming majority of users produce a small set of predictable transformations of a familiar word (capitalize the first letter, append a digit or two, append a common symbol), which attackers' password- cracking wordlists already model extensively. The rule adds little real entropy while measurably increasing the rate at which users write the password down, reuse a slightly modified version across multiple sites, or use a password manager to route around the friction (not itself bad, but evidence the rule is friction rather than protection). NIST SP 800-63B's current position — favor a generous minimum length and check candidates against a database of previously breached passwords — targets the actual attack that matters in practice: credential-stuffing using passwords already known from other breaches, which no amount of composition complexity in a *new* password defends against, and which a breach-database check catches directly regardless of how "complex" the password looks.

Q: A team disables CSRF protection for a REST API authenticated via JWT in the Authorization header, and a colleague flags this as a security regression. Are they right?
Generally no, provided the JWT is genuinely only ever sent via an explicit Authorization header set by JavaScript, and never also accepted from a cookie. CSRF as an attack class depends entirely on ambient authentication — a credential the browser attaches to a request automatically, purely because the request targets a given domain, regardless of which page on the internet triggered it. A cookie is ambient by design; an Authorization header is not — no mechanism exists for a malicious third-party page to force the victim's browser to attach an arbitrary header to a cross-origin request the page itself constructs. Because the precondition CSRF exploits (an automatically-attached credential) doesn't exist for header-based JWT auth, disabling CSRF protection here isn't removing a safeguard against a real risk — it's correctly recognizing the risk doesn't apply to this specific authentication mechanism. The colleague would be right to flag it only if the JWT is also stored in a non-HttpOnly cookie or otherwise made ambient, which would reintroduce the exact precondition CSRF protection exists for.

Q: Content Security Policy is described as "defense in depth" against XSS rather than the only defense. Explain concretely what CSP does and doesn't protect against, and why output escaping is still necessary alongside it.
CSP's script-src directive controls which sources of JavaScript the browser is willing to execute at all — with script-src 'self', even a successfully injected inline <script> tag simply won't run, because the browser refuses to execute script content that violates the declared policy. What CSP does not do is prevent the injection itself, or protect against attacks that don't rely on script execution — HTML injection that defaces a page's visual content, or an attribute-based injection that manipulates a link's destination, can still succeed under a strict CSP, because neither requires executing attacker-controlled JavaScript. CSP also depends entirely on being configured correctly and consistently across every response; a single page or endpoint missing the header, or a policy loosened for a legitimate but careless reason (a wildcard added to unblock a third-party widget), reopens the exact hole CSP was meant to close. Output escaping remains the primary defense because it prevents the injection from succeeding in the first place, regardless of what policy is or isn't correctly applied on any given response — CSP is what limits the blast radius on the response where escaping nonetheless fails.