- Home
- Skills
- Frontend & Web Apps
- Security headers check
More screenshots
Works with the AI Agents you already use
Security headers check
Three missing headers let any site frame your checkout. Find them with plain GETs and get the exact lines to paste for your host
Free
Security headers check
Example session with this skill installed
Check the security headers on https://example.com/. We host on Cloudflare Pages.
- Read your context and instructions
- Compiled the security headers check
Any site can frame this page, and http:// doesn't redirect to https://.
| Severity | Finding |
|---|---|
| High | No framing protection: no frame-ancestors, no X-Frame-Options |
| Medium | No Content-Security-Policy |
| Medium | No HSTS |
| Medium | http://example.com/ answers 200 instead of redirecting to https |
| Low | No X-Content-Type-Options: nosniff |
| Low | No Referrer-Policy (the browser default applies) |
| Info | No Permissions-Policy, no Cross-Origin-Opener-Policy |
The page loads no scripts and no third-party resources, so its CSP can start strict; its one inline <style> block needs 'unsafe-inline' in style-src (or a hash of the block).
The fix, for _headers in the published folder:
/*
Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Strict-Transport-Security: max-age=15552000; includeSubDomains
Permissions-Policy: camera=(), microphone=(), geolocation=()
Cross-Origin-Opener-Policy: same-origin
plus "Always Use HTTPS" in the Cloudflare dashboard for the redirect, and a full CSP sent as Content-Security-Policy-Report-Only first:
default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-src 'none'; form-action 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
After deploying: run the same check; every finding above should read ok.
Connects securely to your tools. The creator never sees your data.
About this skill
Most sites ship without the handful of response headers that stop the commonest attacks on their users: a sign-in or checkout any site can load in an invisible iframe and click through, a first visit over http:// that can be intercepted on public Wi-Fi, a session cookie any script can read. Each is a line in your hosting config. Ask an agent about them and you get a generic list, often with a Content-Security-Policy that breaks your site the day it ships.
This skill reads what your site actually sends and fixes it for your own stack.
What it checks. Framing protection (frame-ancestors, X-Frame-Options); Content-Security-Policy gaps ('unsafe-inline' without a nonce, wildcards, localhost or http:// origins left in production, missing object-src and base-uri); HSTS and whether http:// redirects to https://; nosniff, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy; every cookie's Secure, HttpOnly and SameSite; server version leaks; mixed content; a misconfigured CORS.
Judged by page. The same gap weighs differently on a checkout and on a blog post. Each finding says what an attacker could do on that page, with a severity from high to info, and what's already right is named too.
Fixes for your host, ready to paste. Exact blocks for Vercel, Netlify, Cloudflare Pages, nginx, Apache, Next.js and Express, merged with the headers your site already sends, so a framing rule your own tools rely on isn't overwritten.
A CSP that won't break your site. It drafts a Content-Security-Policy from the scripts, styles, images, fonts and frames your page really loads, keeps your own frame-ancestors, and rolls it out report-only first, with a plan for collecting violations before you enforce.
Passive by design. One plain GET per URL and redirect, the way a browser loads the page: no cookies or credentials sent, no paths guessed, nothing submitted. It reads what your site declares; it doesn't attack it.
- It reads one layer: what the responses declare. It doesn't test for injection, broken access control, CSRF or business-logic flaws, and correct headers don't make a site secure.
- The drafted CSP comes from the HTML as served. Requests made later by scripts (API calls, fonts from stylesheets, analytics) show up only in report-only violations, which is why it ships report-only first.
- Pages behind a sign-in are checked as a signed-out visitor sees them.
- Headers set only for some routes are found only on the URLs you name.
How to use
- 1
Connect your agent to the Agensi MCP
Copy the prompt and paste it into Claude, ChatGPT, Cursor or any agent that supports MCP. It sets up the connection for you. Manual setup
- 2
Sign in to Agensi
Your agent shows a sign-in link. Sign in and click Allow.
- 3
Ask for what you need
Your agent loads this skill and uses it on your task. It always asks before any payment.
Reviews
No reviews yet
Be one of the first to try it. Every listed skill goes through the trust checks below.
Security scanned
Checked by our 8-point scan before listing
Fresh listing
Recently published to Agensi
Free to use
No account required to browse
Trust & safety
Security scan
Security scan passed 15 days ago
- Free with an Agensi account
- Software
Node.js
Permissions
File Scopes
Network access is plain GET requests to the URLs you name and the redirects they return, the way a browser loads a page: no cookies or credentials are sent, no paths are guessed, nothing is submitted. `scripts/check.mjs` reads response headers and the page's HTML to list its own resources; it sends nothing else anywhere. No environment variables are read. The only files written are the report and its JSON.