HTTP Header Checkerserver-backed
Fetch a URL and read its security headers, cookies, caching and CORS configuration.
Enter a URL to fetch its response headers.
R3X sends a single ordinary GET request and reads what comes back. It does not scan ports, guess paths or send anything a browser would not.
Runs on R3X infrastructure. The URL you enter is fetched by an R3X server, because a browser cannot read another site's response headers. The URL is not stored, and the response is not kept after it is returned to you.
Reference
What this is, and what it is not
R3X sends one ordinary GET request and reads the response headers. It does not scan ports, guess paths, send unusual methods, or attempt anything an exploit tool would. The target sees a single normal request from R3XToolsBot/1.0 in its access log.
Every header being present does not make a site secure, and a missing header does not make it vulnerable. These are browser instructions: they change what a browser will do if something goes wrong elsewhere. They are worth setting, and they are not a substitute for the application behind them being correct.
The headers that carry the most weight
| Header | What changes without it |
|---|---|
| Content-Security-Policy | An injected script runs with the full privileges of your origin. CSP is the only header that limits the damage after an XSS bug reaches the page. |
| Strict-Transport-Security | A plain-http link, a typed address or a downgrade attack can put a session on the wire in cleartext once. |
| X-Content-Type-Options | The browser may execute an uploaded file as script because its bytes looked like JavaScript. |
| X-Frame-Options | Your page can be framed invisibly over someone else's, so a click lands on your UI rather than theirs. |
| Referrer-Policy | The full URL — including path and query — is sent to every site your users link out to. |
How a CSP is graded here
A policy that contains 'unsafe-inline' in script-src without a nonce or hash is reported as weak, because it permits exactly the injection CSP exists to stop. A nonce or hash alongside 'unsafe-inline' is accepted: modern browsers ignore the keyword when either is present, and the combination exists for compatibility with older ones.
Missing base-uri is also called out. Without it, an injected <base> tag can repoint every relative URL on the page, which bypasses a script-src that only allows 'self'.
Cookies
Cookie values are never read into the report — only the attributes. The checks are the four that matter: Secure so it never travels over http, HttpOnly so script cannot read it, an explicit SameSite, and the __Host- prefix rules when that prefix is used.
Questions
- Which security headers actually matter?
- Content-Security-Policy does the most work: it is the main thing limiting damage once an injected script reaches the page. Strict-Transport-Security stops a single plain-http request leaking a session. X-Content-Type-Options and X-Frame-Options are one line each and have no downside. The rest are worth setting but change less.
- Does R3X scan my site?
- No. It sends one ordinary GET request and reads the response headers. It does not scan ports, guess paths, try other methods, or send anything a browser would not. Your access log will show a single request from R3XToolsBot.
- My headers are all present. Is my site secure?
- No — it means browsers have been given the right instructions. These headers limit what an attacker can do after a vulnerability exists; they do not remove the vulnerability. A perfect score here says nothing about authentication, authorisation or injection in your application.