How SlaySlop checks Content Security Policy

Clients ask "are we secure?" on a handoff call the way they ask "are we up?" Both questions are too wide for a one-word answer. What I can answer is whether the public pages we scanned show a Content Security Policy that restricts browser content sources—or whether that header is simply missing.

SlaySlop's CSP check "Checks whether browser content sources are restricted by a CSP header." That sentence is what I paste into the portal note when someone wants theater language instead of evidence.

Outcome the check is for

You get Security findings when scanned public responses do not restrict content sources via CSP the way the check expects. The outcome supports process: a checklist item before launch week, a named row in a shared report, a URL list you can send to whoever owns the CDN.

Agencies need that packaging. A raw curl -I pasted in Slack does not survive reorgs. A ranked finding with page context does. So does a follow-up scan after the edge config changes—because launch week is when someone "temporarily" removes the header to unblock a tag.

Boundaries

Read-only. Public websites. Permission required. Not a pentest. Not a substitute for an XSS engagement. Cross-site scripting is a separate check using known vulnerability templates on public pages. CSP is the header-restriction question.

SlaySlop does not push header changes to your edge. Fix prompts can help engineers draft a change from evidence; the deploy is still yours. Do not scan properties you do not own, manage, or have permission to test.

Uptime is also not this check. Availability status only records whether the public site responds. I have watched teams celebrate a green uptime tile while checkout accepted scripts from anywhere the browser would load. Keep the rows separate in the portal so nobody confuses "reachable" with "restricted."

Happy path: how the signal is observed

Aligned with published product language for Security:

1. Crawl and request public pages in the scan.
2. Inspect whether a CSP header restricts browser content sources.
3. Attach findings to the pages where the gap appears.
4. Keep the row beside HSTS and Frame protection so header work stays one workstream.
5. Export or share the report without dumping the entire workspace on the client.

The Security product framing starts with inspecting HTTPS and headers—HSTS, CSP, frame protection—before secrets hunting. That order matches how I brief junior PMs: browser controls first, then the spookier findings.

# Operator pre-check on a host you may test
curl -sI "https://client.example.com/" | rg -i 'HTTP/|content-security-policy|strict-transport|x-frame'

Handoff CSP notes
urls: /, /pricing, /checkout
csp_present: yes|no|report-only
owner: CDN | app | unknown
ticket:

Pitfalls in interpreting the result

Silence on the marketing homepage does not prove the app subdomain is covered if it was not in scope. A report-only header is not the same operational story as an enforcing header—say so in the portal. Client CMSes that inject scripts will fight a tight script-src; plan the allowlist with whoever owns tags, or the next deploy will "fix" the policy by deleting it.

Do not synonym-cycle the finding into "security hygiene" with no URL. Keep "CSP missing on /checkout" searchable. Product examples on SlaySlop already narrate missing CSP with page-coverage evidence; match that specificity in your note.

Why ops people should care about the header tab

I have sat on calls where design looked perfect and the security slide was a shrug. CSP is one of the few checks you can explain in a sentence without a whiteboard: the browser was never told which script sources to trust. When the fix lands, rescan. Follow-up scans exist so you can show the row cleared instead of promising it cleared. If tightening CSP breaks a tag, Console errors and Failed requests will often light up; keep those owners in the same thread so launch week does not turn into three disconnected Slack channels.

What I tell the client in one breath

"We checked whether your public pages send a Content Security Policy that restricts what the browser will load. Here are the URLs that were missing it or only on report-only. Here is the ticket owner. Here is the rescan after the CDN change."

If I cannot say those four sentences, the check result is not ready for handoff yet—even if someone on the team insists the platform "handles security."

Related next step

Run the permissioned scan, read CSP next to HSTS and Frame protection, file one CDN ticket with URLs, then rescan before you call the site handoff-ready. Soft link: Content Security Policy and Security and secrets.