Security scan: find config mistakes

A report-only security scan that finds leaked API keys, open databases and exposed files, with a copy-paste AI fix prompt for each issue.

The Amabrik security scan reads your live site the same way any visitor or bot can, then tells you where you’ve left the door open. It looks for the high-confidence configuration mistakes that leak data: a secret key shipped in your page code, a database anyone can read, an .env file you can open in a browser, and missing security headers. For each thing it finds, it hands you a plain-English explanation and a copy-paste AI fix prompt you drop into Claude, ChatGPT or Cursor.

It’s included on every plan, and it’s report-only. It reads what your site already serves in public and analyzes it. It never sends attack payloads, never logs in, never writes anything, and never changes your site. Running it is safe on a live production site.

What it is not

It helps to be clear about the boundaries, because “security scanner” means a lot of different things:

  • It is not antivirus or malware scanning. It doesn’t hunt for injected malware, backdoors or infected files on your server.
  • It is not a firewall or WAF. It doesn’t sit in front of your traffic and block requests. It’s a check you run, not a shield that runs all the time.
  • It is not a penetration test or active DAST. It doesn’t try live SQL injection, XSS payloads or any attack against your site. It reads what’s already public and reasons about it.
  • It is not attack-surface management. It scans the one domain you verified, not your whole external footprint.

Think of it as a careful read-through of your public configuration, written so the person who built the site can act on it, not a 40-page report for a security team.

Verify your domain first

The scan only runs on a domain you’ve proven you own. That’s deliberate: a scan probes a site for exposed data and weak points, so we only ever point it at a site you control. An unverified domain can’t be scanned.

To verify:

  1. In your dashboard, open Security. If your current site’s domain isn’t verified yet, you’ll be asked to verify it before you can scan.
  2. A popup shows a DNS TXT record to add at your DNS provider: a Type (TXT), a Name / Host, and a Value. Copy them in.
  3. If your DNS provider supports one-click setup, an Apply automatically button adds the record for you. You still click Verify afterward to confirm it.
  4. No DNS access? Switch to the meta tag fallback: add the tag inside your homepage <head>, publish, then click Verify.
  5. Click Verify. If the record isn’t found yet, DNS changes can take a few minutes (and up to 24 hours) to spread worldwide, so wait a little and click Verify again.

Once the domain shows a green check, scanning is unlocked. The same verification also unlocks the SEO and AEO scan, so you only do it once per site.

Run a scan on demand

With a verified domain, open Security and run the scan. It enqueues a crawl and waits for the result. A small site finishes in seconds; a large site can take a minute or two, because the crawl is split into small passes so it never overloads a single request.

When it’s done, you get:

  • A Security score out of 100, weighted by how serious the findings are.
  • The number of pages scanned.
  • A list of findings, worst first, each with a plain-English impact and a copy-paste AI fix prompt.

The scan starts at your homepage and follows internal links across your own domain, reading each page’s HTML, its response headers, and its JavaScript bundles. It also runs a small set of site-wide checks once (DNS email records, well-known file paths, the HTTP-to-HTTPS redirect), so a site-wide issue like a missing header is reported once, not once per page.

What it checks

Here’s each kind of finding, in plain English.

Secret keys shipped in your code. The scan reads your pages and JavaScript bundles for credential patterns that should never reach a browser: a Stripe live secret key, an AWS access key, an OpenAI or Anthropic key, a GitHub token, a SendGrid or Resend key, a private key block, a database connection string with a username and password in it, and hardcoded credentials. Anyone can read these with “view source,” so a real one is flagged as critical. A publishable or public-by-design key (for example a Google Maps key meant to be in the browser) is treated as a low-severity “restrict this,” not a leak.

A database anyone can read. If your page references a Supabase, Firebase or Turso backend, the scan notes it and checks whether the public-facing API hands back data without authentication. With Supabase, that means Row Level Security being off, so the anon key (which is supposed to be public) can pull every row: users, orders, messages. This is the exact pattern behind many AI-built app breaches.

Exposed sensitive files. The scan probes for well-known files that should never be downloadable: /.env, /.git/config and /.git/HEAD, /config.json, /.DS_Store, /backup.zip, /wp-config.php.bak, and /.aws/credentials. A real exposed .env or .git folder leaks your secrets and source straight to anyone who asks for the URL.

Missing security headers. The scan checks for the browser-level defenses sent in your response headers: Content-Security-Policy, Strict-Transport-Security (HSTS), X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. These are defense-in-depth against script injection, clickjacking and protocol downgrade, so a miss is a medium or low finding, not an alarmist critical.

Insecure cookies. Session cookies set without the Secure, HttpOnly or SameSite flags can travel over plain HTTP, be stolen by injected scripts, or be sent in cross-site requests.

TLS and transport problems. The scan flags a site whose plain-HTTP version doesn’t redirect to HTTPS, and mixed content (an HTTPS page that pulls in a resource over plain HTTP). A successful HTTPS fetch already proves your certificate is valid and not expired.

Over-permissive CORS. If an endpoint reflects any website’s origin and also allows credentials, any site can read your authenticated data. That gets flagged as high.

Email spoofing gaps. The scan reads your DNS and flags a missing SPF or DMARC record, which is what lets anyone spoof email from your domain.

Technology disclosure and third-party scripts. It notes when your server advertises its exact stack and version (an easy hint for an attacker), and when an external script loads without a Subresource Integrity hash. It also runs WordPress-specific checks (exposed version, open XML-RPC, user enumeration, a public debug.log, an uploads directory listing) when it detects WordPress.

Compliance gaps. It notes when no privacy policy link or cookie consent banner is detected on the page. (You can add a compliant banner with the Amabrik Cookies widget.)

Read the report and use the AI fix prompt

Every finding has three parts: what it is in plain language, why it matters, and a copy-paste AI fix prompt. The prompt is the point. It’s written for the person who shipped the site, not a security engineer, and it’s ready to paste straight into Claude, ChatGPT or Cursor. Your AI assistant then writes the actual fix for your code.

The prompts are built so a fix never breaks a working site. Anything that adds a restriction (a Content-Security-Policy, a CORS change, cookie flags) ships with three things baked in:

  1. Deploy report-only first. A new CSP, for example, goes out as Content-Security-Policy-Report-Only so it blocks nothing and only reports, then you switch it to enforcing once you’ve confirmed everything still works.
  2. A “keep these working” allowlist. The prompt tells the AI to keep your forms, your payment provider, your analytics and your Amabrik widget directives working, so a CSP doesn’t accidentally kill checkout or hide a widget.
  3. A test-after checklist. Items like “submit a contact form and confirm it sends,” “run one test payment end to end,” and “check the console for blocked-resource errors.”

For a leaked secret, the prompt walks the AI through finding the key, moving it to a server-only environment variable, refactoring browser code to call a server route, rotating the key in the provider’s dashboard (because the old one is compromised), and confirming it’s gone from the built bundle. Each prompt also asks the AI to fix the same issue everywhere else on the site, not just the one page, so it can’t quietly recur.

The fix prompts are available once you’re on a paid plan. On the free trial, the scan still runs and shows you every finding with its plain-English impact; the copy-paste prompts are unlocked when you upgrade.

If something looks wrong, you can mark a finding as a false positive to hide it from this and future scans, and restore it later if you change your mind.

Scheduled scans and notifications

You don’t have to remember to scan. Behind the gear icon on the Security page, set up automatic scans and alerts per site:

  • Frequency: Off, Daily, Weekly or Monthly. Each site runs in its own off-peak window (around 3am in your local time, spread across the day so scans don’t all fire at once).
  • Email me: “Only new critical or high,” “After every scan,” or “Never.”
  • Notification email: where alerts go.
  • Webhook (optional): paste a Slack, Discord, Zapier, n8n, Make or custom endpoint URL. Amabrik detects the destination and sends the format it expects.

Scheduled scans are smart about noise. Before a scheduled scan crawls, it checks whether your homepage is byte-for-byte identical to the last scan. If nothing changed, it skips the whole crawl. And alerts are diff-based: you’re told only about issues that are new since the last scan, never reminded about the unchanged state. The email carries each new finding with its ready-to-paste AI fix prompt right inside it, plus a link to the full report.

One thing to know: Amabrik keeps only the latest scan per site. Each new scan replaces the previous one. We’re not a data store, so storage stays flat as you grow. If you want a record of a scan, download the report as a PDF from your dashboard.

A manual scan you run yourself always runs fresh (it’s you asking for a result right now), and its results are shown to you live rather than emailed.

Per-plan scan limits

The limit is how many pages a single scan crawls, set by your plan. A small site scans fewer than the cap; the cap is a ceiling, not a target.

PlanPages crawled per scanAI fix prompts
Free trialHomepage only (1)Locked
StarterUp to 200Included
BusinessUp to 500Included
AgencyUp to 3,000Included

A site bigger than your plan’s cap is never an error: the scan covers up to the cap and the report shows an upgrade notice so you know there’s more to scan.

Why it avoids false positives

A fake critical destroys trust, so the scan is tuned to be precise rather than loud:

  • Public-by-design values aren’t flagged. A publishable Stripe key, a Supabase anon key or a Google Maps key is meant to be in the browser, so it’s never called a leak. The real database risk is checked by testing whether the data actually comes back without auth, not by pattern-matching a public token.
  • A 200 status isn’t enough to call a file exposed. Single-page apps serve their index.html for every path, so a /.env URL on an SPA often returns a normal-looking 200. The scan reads the body and confirms it actually looks like the file (an .env has KEY=value lines, a .git/config has section headers) before flagging it. A parked SPA page is never reported as an exposed file.
  • Secret patterns demand real key bodies. The patterns require the actual shape of a credential, so a Tailwind class name or a crypto library’s bundled demo key doesn’t trip a false leak.
  • Hardening misses are scored honestly. A missing header is defense-in-depth, scored medium or low, so it never alone tanks your score into the red.

FAQ

Does the security scan replace antivirus or a firewall?

No. It’s a configuration check, not a runtime defense. It doesn’t scan your server for malware (antivirus) and it doesn’t sit in front of your traffic blocking requests (a firewall or WAF). It finds the mistakes that leak data, like a secret in your code or an open database, and tells you how to fix them. Keep your antivirus and firewall; this is a different layer.

Will the scan break my site?

No. It’s report-only. It reads what your site already serves to the public and analyzes it. It never logs in, never sends attack payloads, never writes anything, and never changes your site. It’s safe to run on live production.

Will the fixes break my site?

No. The AI fix prompts are written to leave working forms, payments, analytics and widgets untouched. Restriction fixes deploy in report-only mode first, ship with a “keep these working” allowlist, and come with a test-after checklist. A fix that breaks checkout is not a fix.

How often should I scan?

At least monthly, and after every deploy or new integration. The riskiest moment is right after you ship a change, especially with AI-assisted code. Turn on a schedule (daily, weekly or monthly) so a new leak gets caught early instead of months later.

Are the API keys in my front-end code a problem?

It depends on the key. A publishable or anon key is designed to be public, and its security comes from access rules on the backend, so Amabrik never flags it. A secret or service-role key (a Stripe secret key, an AWS key, a database service-role key) must never reach the browser. If one is in your page, anyone can read it, and that’s what the scan flags as critical.

My site has no login or database. Is it worth scanning?

Yes. Most findings have nothing to do with a login: an exposed .env file, missing security headers, a broken HTTP-to-HTTPS redirect, insecure cookies, a public .git folder or a missing SPF record all apply to a plain marketing site. Bots scan for these automatically, so a small site is still a target.

Do I need to install anything or know how to code?

No. You verify your domain once with a DNS record (or a meta tag), then scan from the dashboard. There’s no agent to install and no code to read. Each finding comes with a copy-paste AI fix prompt your AI assistant turns into the actual change.

Why does Amabrik only keep my latest scan?

Amabrik isn’t a data store. Each scan replaces the previous one so storage stays flat as you grow. If you want to keep a copy of a report, download it as a PDF from your dashboard.

Last updated June 22, 2026

Still stuck?

Open the widget's Help tab in your dashboard, or send us a message. We answer every one.

Contact support