A regex "sanitiser", a GET delete link, and a CSP that permits everything inline

The regex is being asked to parse a context-free grammar with a tool that has no grammar. HTML has quoting rules, character references, comments, CDATA-like sections, foreign content (SVG/MathML), null bytes, and attribute separators that are not whitespace - a pattern cannot enumerate all of them, and every enumeration you add is another patch to a moving target. The proposed fix (block <img> and onerror) fails immediately to onload, onfocus with autofocus, onanimationend, <svg><a xlink:href="javascript:...">, <math><mtext><script> style nesting, <a href="jav&#x09;ascript:...">, or an event handler split across oddly quoted attributes that the on\w+= pattern reads differently from the browser.

Correct architecture, in order of preference:

1. Do not accept HTML. Store plain text and render with textContent. If bold and links are the only requirement, use a constrained markdown subset rendered server-side into an allowlisted tree.
2. If HTML must be accepted, parse it with a real parser (an HTML5-compliant library) and rebuild the output from an allowlist: permitted element names, permitted attributes per element, URL schemes restricted to http, https, mailto with rel="noopener noreferrer" on links, and all other nodes dropped or text-escaped. Mature sanitisers (DOMPurify, OWASP Java HTML Sanitizer, Bleach) exist; do not hand-roll.
3. Sanitise on input and again on output, because the stored corpus contains three weeks of hostile content and because rendering contexts change. Encode at the sink as the final defence: innerHTML should be replaced with textContent or DOM building wherever the content is not deliberately allowed HTML.

It is also worth noting the researcher did not need to break the regex cleverly - the on\w+= strip runs after the script strip and does not understand attribute boundaries, so a handler inside a quoted attribute value survives.

The policy as written provides almost nothing. 'unsafe-inline' in script-src re-enables inline <script> blocks, inline event-handler attributes, and javascript: URLs - the exact vectors in play - and when a nonce or hash is also present, browsers ignore 'unsafe-inline' in supporting browsers, but here there is neither. script-src 'self' also matters less than people think, because 'self' permits any script served from the origin, so an uploaded file or a JSON endpoint misinterpreted as script can execute.

Better target policy:

• script-src 'nonce-<random>' 'strict-dynamic' with a fresh nonce per response, and no 'unsafe-inline', no 'unsafe-eval'.
• object-src 'none', base-uri 'none' (blocks <base> hijacking of relative URLs), frame-ancestors 'none' (clickjacking), form-action 'self'.
• default-src 'self' with explicit img-src, style-src (prefer hashes over 'unsafe-inline'), connect-src limited to the APIs actually called.
• Consider Trusted Types (require-trusted-types-for 'script') - it makes assigning strings to innerHTML throw, which would have stopped this bug at the sink.
• Roll out with Content-Security-Policy-Report-Only plus a report-uri/report-to endpoint first, so you find violations before you break the site.

Position: CSP is a mitigation layer, not a fix. It limits what an injected script can do if it executes, but it cannot stop markup injection itself, cannot stop data exfiltration through permitted channels such as img-src if that is broad, and does nothing for the server-side consequence of the request. Sanitisation and output encoding must remove the injection; CSP is what saves you when a sanitiser has a zero-day. Ship both, and treat the CSP as an alarm as well as a control.

Cookie. Set it server-side with Set-Cookie: __Host-sid=<value>; Path=/; Secure; HttpOnly; SameSite=Lax (or Strict for the admin surface). Requirements and reasoning: HttpOnly makes it unreadable from JavaScript, so an XSS can still act as the user through the browser but cannot exfiltrate the token to be replayed later from elsewhere. Secure prevents it being sent over plain HTTP and blocks most network-level leakage. __Host- forces Secure, an origin-wide Path=/, and no Domain attribute, which prevents a compromised sibling subdomain from setting a cookie for your host. Setting cookies from document.cookie cannot apply HttpOnly at all, which alone is reason to move it to the server. Add Max-Age/Expires and rotate the session id on privilege change and at login.

Delete action. SameSite=Lax sends the cookie on top-level GET navigations from other sites, and only withholds it from cross-site subresource requests and cross-site POSTs. A delete implemented as a GET link is therefore fully exploitable: an attacker page that navigates the moderator to /admin/comments/42/delete carries the cookie and performs the action. SameSite=Strict would block that particular navigation but breaks ordinary inbound links and is not a substitute for a token.

The fix is to change state with POST (or DELETE) only, never GET, and to require an anti-CSRF token: a per-session random value stored server-side, embedded in the form as a hidden field or sent as a header, compared in constant time on the server. Add an explicit confirmation step for bulk actions, and consider Origin/Referer checking as a secondary signal. Then apply SameSite=Lax as defence in depth, and make the endpoint idempotent-safe so a duplicated request cannot delete twice beyond the first no-op. Also verify authorisation per object - that the comment belongs to a resource this moderator may moderate - so the endpoint is not relying on obscurity of the id.