Content Security Policy is a browser contract: which scripts, styles, frames, and other resources this document may load. OWASP is clear that CSP sits on top of sanitization and safe coding; it does not replace them. This piece is a step plan from Report-Only to enforcement.

Step 0 — Know what you serve today

curl -sL -D csp-headers.txt -o csp-body.html -w 'final_url=%{url_effective}\n' https://example.com/
grep -i '^content-security-policy:' csp-headers.txt
grep -i '^content-security-policy-report-only:' csp-headers.txt

• No Content-Security-Policy: line: no enforced policy was found in the response headers; also check the HTML for a <meta http-equiv="Content-Security-Policy"> tag.
• Only Report-Only: useful for learning; it does not stop a bad script.
• Prefer the HTTP header over meta when you need frame-ancestors or reporting (WSTG-CONF-12).

Repeat on /login or /account if you are allowed to. Policies often differ by route.

Step 1 — Draft a candidate policy

Start from OWASP’s basic same-origin example only as a starting point (not Strict CSP, not a ready setting for every site):

Content-Security-Policy-Report-Only: default-src 'self'; frame-ancestors 'self'; form-action 'self';

A missing object-src alone is not proof of weakness — it can fall back to default-src. When you tighten later, strict examples often add object-src 'none' and base-uri 'none', and move script-src to nonces or hashes.

Step 2 — Ship Report-Only on staging, then production

Deploy the candidate as Content-Security-Policy-Report-Only. Review what would be blocked in the browser console and at your reporting endpoint. Report-Only itself does not break the site; it surfaces violations that an enforced header would stop.

Allow or refactor legitimate assets (analytics, fonts, embeds) deliberately. Do not widen script-src to * just to silence noise.

Step 3 — Enforce the same policy

When the report stream is quiet for the paths that matter, move the same directives to Content-Security-Policy. MDN notes both headers can coexist: keep enforcing one policy while reporting on a stricter candidate.

Do not park forever in Report-Only. A year of violation logs is not a browser block.

Step 4 — Re-check after every frontend change

New packages and third-party scripts often reintroduce 'unsafe-inline' or new hosts. Re-run the curl check on homepage and session pages after releases.

Soft policies still fail the real goal

If script-src allows 'unsafe-inline' without a nonce or hash, or allows 'unsafe-eval' / bare *, you may clear a “missing header” finding and still leave the XSS path open. Aim for nonce- or hash-based strict CSP rather than a huge host allowlist.

Limits

A clean CSP check does not prove the app is free of XSS or that every dependency is trustworthy. Outside tools only see returned headers and bodies.

About us

We build HackerMe, an automated website security scanner by Agura / OMC Group. Security headers are part of every website scan; a sample finding is “Missing Content-Security-Policy header.” Deeper CSP analysis can check policy quality on Standard and higher scan types. HackerMe offers a free scan on a domain you own or have explicit permission to test: https://brandingme.ai/app/r/Cxr3PSelcezVc6zxoLFyzw

Sources

• MDN CSP: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
• OWASP CSP Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
• OWASP WSTG-CONF-12: https://wstg.owasp.org/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management/12-Content_Security_Policy/

Someone finds a problem on your site: an exposed file, a misconfigured header, a login bug. They want to tell you. Where do they go? A contact form that routes to sales? A generic info@ inbox? A social media account?

RFC 9116 answers that with a small text file at a fixed location: /.well-known/security.txt. It does not fix anything by itself. It makes the first step of a responsible report predictable. Here are six checks for setting it up and keeping it honest.

1. Is the file where clients will look? (safe on any public site)

curl -s -D headers.txt -o security.txt https://example.com/.well-known/security.txt
head -1 headers.txt; grep -i '^content-type' headers.txt; head security.txt

You want a 200, a text/plain content type, and the file over HTTPS; RFC 9116 places it under /.well-known/ and requires HTTPS. Look at the body too: some sites answer every path with 200 and an HTML error page, or redirect to the homepage, which is not a security.txt.

2. Does it have the two required fields? (safe on any public site)

RFC 9116 requires Contact and Expires. A minimal file:

Contact: mailto:security@example.com
Expires: 2027-10-31T22:00:00.000Z
Preferred-Languages: en, he
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy

At least one Contact (a mailto:, tel: or https: URI) and exactly one Expires: the RFC says Expires must always be present and must not appear more than once. A file with only a contact, or with several expiry dates, needs fixing. Open each URI in the optional fields as well; nothing checks that they lead somewhere real.

3. Has it expired? (safe on any public site)

The RFC recommends an Expires value less than a year into the future, so stale files are noticeable. Compare the value with today's date.

A date in the past tells researchers the information may be out of date. Put the renewal in the same calendar as your domain and certificate renewals.

4. Does Canonical match where it is served? (safe on any public site)

Canonical is optional. If you use it (useful when you sign the file or serve it on several hosts), it lists the URIs where this exact file lives, and the RFC says that when Canonical fields are present and none of them matches the URI the file was retrieved from, the contents should not be trusted. A file with no Canonical field is still valid; a Canonical pointing at a different domain, a staging host or http:// is the problem.

It also does not say anything about subdomains. Per the RFC, a file applies to the host it is served from; shop.example.com needs its own file or a redirect you have thought through.

5. Signed or not? (maintainer check)

The RFC recommends signing the file with an OpenPGP cleartext signature. It is optional. If you sign, publish the signing key somewhere you control and re-sign every time you edit the file. Do not treat the Encryption field as the signing key: it points to a key for encrypting reports to you, and RFC 9116 warns researchers not to assume that key is the one used for the signature. A signature that no longer verifies is worse than none, because it trains readers to ignore failures.

6. Does a message to the contact reach a person? (maintainer check)

This is the check no scanner can do for you. Send a test message to the listed address from outside your organization and confirm:

• it is not caught by a spam filter,
• it reaches more than one person,
• someone knows what to do next.

The OWASP Vulnerability Disclosure Cheat Sheet recommends a clear process for receiving and handling reports. The file only helps if that process exists behind it.

What security.txt does not do

• It does not make a site safer. It is a contact card.
• It does not grant permission to test your site unless your policy says so. If you have rules for researchers, put them on the Policy page.
• A valid file is not evidence that reports are handled well.

About us

HackerMe runs automated checks from the outside on a domain you own or have explicit permission to test. It sees only what your server returns, so treat its results as a starting point. https://brandingme.ai/app/r/1s5brArmi4E9vtT-nWbcZg

Sources

• IETF, RFC 9116, A File Format to Aid in Security Vulnerability Disclosure: https://www.rfc-editor.org/rfc/rfc9116
• securitytxt.org (project site by the RFC authors): https://securitytxt.org/
• OWASP, Vulnerability Disclosure Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html

A session cookie is often the only thing that proves a request comes from a logged-in user. Its attributes decide when the browser sends it and whether scripts can read it, and the session lifecycle decides how long it stays valid. This post covers seven checks, with what you should see, what counts as a finding and what a pass does not prove. Background: MDN: Set-Cookie, the OWASP Session Management Cheat Sheet and RFC 6265.

1. See what the site sets (safe on any public site)

curl -sI https://example.com/ | grep -i '^set-cookie'

Session cookies are usually issued at login, so on your own app also inspect the login response in the browser dev tools (Network tab).

• Doesn't prove: anything about cookies set later or by JavaScript. One response is a sample.

2. Secure (safe on any public site)

RFC 6265 says a cookie with Secure is sent only over channels the browser considers secure, which in practice means HTTPS.

• Expected: every session or authentication cookie has Secure.
• Finding: a session cookie without it. OWASP also warns against switching a session between HTTP and HTTPS, which exposes the session ID.
• Doesn't prove: that the whole site is served over HTTPS. Check redirects and HSTS separately.

3. HttpOnly (safe on any public site)

HttpOnly stops scripts from reading the cookie, for example through document.cookie (MDN).

• Expected: session cookies have HttpOnly. Cookies that front-end code must read should not hold the session ID.
• Finding: a session cookie readable from JavaScript.
• Doesn't prove: that the site is safe from XSS. MDN notes that an HttpOnly cookie is still sent with requests made by JavaScript, so a script running on the page can still act as the user.

4. SameSite (safe on any public site, plus maintainer check)

SameSite controls whether the cookie goes out with cross-site requests. Strict sends it only for same-site requests. Lax also allows top-level navigations that use safe methods such as GET. None sends it everywhere and requires Secure.

• Expected: an explicit SameSite value that matches how the app is used. MDN notes that only some browsers default to Lax when the attribute is missing, so don't rely on the default.
• Finding: no SameSite, or SameSite=None on a session cookie with no clear cross-site need.
• Doesn't prove: CSRF protection. The OWASP CSRF Prevention Cheat Sheet points out that Lax does not stop a state-changing action reachable by GET, and that SameSite is scoped to the site, not the origin. Checking for state-changing GET endpoints is a maintainer check.

5. Scope: Domain, Path and prefixes (safe on any public site)

MDN explains that omitting Domain makes a host-only cookie, while setting it shares the cookie with every subdomain.

• Expected: no Domain attribute unless subdomains truly need the session. A __Host- prefix enforces this: the browser accepts such a cookie only with Secure, Path=/ and no Domain.
• Finding: Domain=example.com on a session cookie when some subdomains are run by third parties.

6. Session ID renewed at login (your own sites only)

OWASP says the session ID "must be renewed or regenerated" after any privilege level change, most commonly at login. Using a test account, note the session cookie value on the login page, log in, and compare.

• Expected: a new value after login.
• Finding: the same value before and after login, which can make session fixation possible. See OWASP WSTG: Testing for Session Fixation.
• Also check: that the session ID never appears in a URL. OWASP notes that URLs leak through logs, history, bookmarks and the Referer header.

7. Logout and timeouts end the session (your own sites only)

# Replace with the cookie value you copied before logging out
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Cookie: session=OLD_VALUE" https://example.com/account

• Expected: after logout, the old value no longer gives access (typically a redirect to login or a 401/403). The same should happen after the idle and absolute timeouts you have set.
• Finding: the old value still returns account content. Clearing the cookie in the browser is not enough if the server still accepts it (OWASP WSTG: Testing for Logout Functionality).
• Note: OWASP says timeout values depend on how critical the application and its data are, so they are a maintainer decision, not a fixed number.

Example: reading one result

$ curl -sI https://example.com/login | grep -i '^set-cookie'
set-cookie: session=7f3c...; Path=/; Domain=example.com; HttpOnly

HttpOnly is present. Secure and SameSite are missing, and Domain shares the cookie with every subdomain. Those are findings to fix, for example by renaming the cookie to __Host-session with Secure; HttpOnly; SameSite=Lax; Path=/. Even a perfect header line says nothing about renewal at login or invalidation at logout. Checks 6 and 7 cover that.

Make it routine

Re-run these checks whenever you change the login flow, add a subdomain or update session settings, and record the expected attributes for each cookie. A passing result is a starting point, not a guarantee.

Disclosure: we are the team behind HackerMe, a free automated website security scanner: https://hackerme.ai. The checks above work without it.

What would you add to this list? We would like to hear it in the comments.