The short version

• Oct 20 to 26, 2026: 645 checks on 633 unique domains (our own test domains excluded).
• Using each domain's latest grade: 260 domains (about 41%) scored A or B, and 372 (about 59%) scored C, D or F. One had no grade.
• The public counter read 650 total checks as of Mon Oct 26, 2026, about 11:55 AM Central.
• On the public board, the 20 lowest results were 4 F, 9 D and 7 C. The 20 highest were all A (19 scored 100, one scored 95).

These sites are ones people chose to type in, not a random sample. Read the method notes before you quote any of this.

Grade tables

All domains checked, Oct 20 to 26, 2026 (latest grade per domain, 633 domains):

The query reports A/B and C/D/F as groups, so I am not giving a count for each single letter.

Newest 10 on the public board:

Scores in this slice run from 46 to 100.

20 lowest on the board:

20 highest on the board:

The board tables are a small, opt-in slice. Do not read them as the overall picture; the first table is the overall one.

How grading works

• A is 90 and up, B is 75 and up, C is 60 and up, D is 40 and up, and F is below 40.
• Each problem takes points off based on how serious it is. A serious problem also caps the grade. One critical finding keeps a site at F. One high-severity finding keeps it at D or below.
• The free check shows only the worst problem it found, with a plain-English fix. It does not list everything.

What the checker looks at

It only reads what any visitor can already see. It does not log in, guess passwords or try to break anything, and it follows robots.txt.

• Does the padlock (HTTPS) work, and does http redirect to https?
• Are the usual browser safety settings (security headers) set?
• Are private files like /.env or other sensitive paths reachable from the outside?
• Do the pages load?

This is not a penetration test. It cannot see behind a login and it cannot judge your business logic.

Method notes and limits

• Source: a read-only query of the free check results table in our database.
• Window: Oct 20 to 26, 2026.
• Latest grade per domain: if a domain was checked more than once, only its most recent grade is counted in the A/B vs C/D/F split. The 645 figure counts every check, including repeats.
• Exclusions: our own test domains, deployvet.com and example.com. Some other test-looking domains may remain in the data, so treat the counts as approximate.
• Not a random sample. These are sites people typed in themselves. Sites whose owners care about security, or who suspect a problem, may be more likely to run it, and I cannot tell which way that pushes the numbers.
• The 650 total on the public counter and the 645 in the query are different counts (different filters and time of day). I am using the query for the split and the counter only as a running total.
• The public board shows only 50 rows at a time (20 highest, 20 lowest, 10 newest), opt-in, with masked domains. I cannot tell you what kinds of sites they were, and I will not name anyone.
• Not every site checked was made with an AI or no-code tool. I do not have a clean way to tell, so I will not make claims about "AI-built sites" as a group.
• Scores can change as the scanner changes. A grade is a snapshot from the day it was run.
• Automated checks make mistakes, both missing things and flagging things that are fine.

What I do not know yet

I do not have a verified breakdown of which problems come up most often, so I am not going to guess at one. If I get that checked properly, I will post it.

Your turn

If you have shipped something built with an AI tool, what is the last thing you check before you share the link?

I build DeployVet. If you want to try the free check: https://deployvet.com/?utm_source=hashnode&utm_campaign=datapost

They cost nothing. They take minutes to add. And a lot of sites, from hand-built WordPress sites to apps made with Lovable or Bolt, ship without them.

Here's how to check yours and fix the gaps.

Step 1: Look at your headers (2 minutes)

Option A: your browser. Open your site in Chrome or Firefox. Press F12 (or right-click and choose Inspect). Click the Network tab, then reload the page. Click the first row, which is your page itself. Scroll to Response Headers.

Option B: one command. If you have a terminal:

curl -sI https://yoursite.com

The -I asks for headers only. You'll get a short list back.

Now look for these four names:

1. strict-transport-security
2. x-content-type-options
3. x-frame-options (or frame-ancestors inside content-security-policy)
4. referrer-policy

Write down which ones are missing.

Step 2: Know what each one does (1 minute)

Strict-Transport-Security (HSTS). Tells the browser: "Only ever talk to me over https." Without it, a visitor who types your address without https can land on the plain, unprotected version first. A common value:

Strict-Transport-Security: max-age=31536000

Only add this once https works everywhere on your site, including subdomains you plan to cover. Browsers will remember it for the full max-age.

X-Content-Type-Options. Stops the browser from guessing what a file is. One value, always the same:

X-Content-Type-Options: nosniff

X-Frame-Options. Stops other sites from loading your page inside a hidden frame and tricking people into clicking things (this is called clickjacking):

X-Frame-Options: DENY

If you embed your own pages in frames, use SAMEORIGIN instead.

Referrer-Policy. Controls how much of your page address gets passed along when someone clicks a link off your site. Useful if your URLs ever hold things like reset tokens or order numbers:

Referrer-Policy: strict-origin-when-cross-origin

Step 3: Turn them on (2 minutes, depends on your host)

Vercel. Add a vercel.json in your project root:

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Strict-Transport-Security", "value": "max-age=31536000" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" }
      ]
    }
  ]
}

Netlify. Add a file named _headers to your publish folder:

/*
  Strict-Transport-Security: max-age=31536000
  X-Content-Type-Options: nosniff
  X-Frame-Options: DENY
  Referrer-Policy: strict-origin-when-cross-origin

Cloudflare in front of your site. Use Rules, then Transform Rules, then "Modify Response Header," and add each one. HSTS has its own switch under SSL/TLS, then Edge Certificates.

WordPress. Many hosts have a security headers setting in their control panel. If yours doesn't, a well-known security plugin can add them. Pick one plugin, not three.

Wix, Squarespace, Shopify. You usually can't edit headers yourself. The platform sets them. Check what you have with Step 1. If something important is missing, ask their support.

Step 4: Check again

Reload with F12 open, or run the curl command again. All four should show up. Then click around your site for a minute. If something broke (usually an embedded video or a payment widget inside a frame), that's almost always X-Frame-Options. Switch it to SAMEORIGIN or allow that one page.

What about Content-Security-Policy?

CSP is the strongest header and the easiest to break your site with. It lists exactly where scripts, images and styles may load from. Start with Content-Security-Policy-Report-Only so the browser reports problems without blocking anything. Fix what it reports, then switch to the real header. Give it its own afternoon.

The honest part

Headers are seatbelts, not a lock. They won't fix a database that anyone can read or a secret key sitting in your front-end code. But they're the cheapest fix on this list, and the first thing a stranger can see.

If you'd rather not do Step 1 by hand, DeployVet runs a free outside check of your site. It looks at headers, the padlock, exposed files and broken pages, and explains what it finds in plain English: https://deployvet.com/?utm_source=hashnode&utm_medium=article&utm_campaign=howto

It reads what's public, the same way a stranger would. It isn't a penetration test.

What is public and what is not

Your project ships two keys. The anon key is designed to sit in your front end. The service_role key bypasses Row Level Security completely and must only ever live on a server. If you used an AI builder, the first thing to confirm is that nothing named service_role appears in your deployed JavaScript, and that no secret sits behind a VITE_ or NEXT_PUBLIC_ prefix.

Because the anon key is public, your safety rests entirely on RLS and grants. So test those.

Test 1: which tables have RLS off?

select tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

Any row with rowsecurity = false is open to anyone with the anon key. Tables created through the dashboard editor usually get RLS on by default. Tables created by SQL, which is what AI tools often do, do not unless the SQL says so.

Test 2: ask the API as a stranger

Open a terminal and run this with your own project URL and anon key:

curl "https://YOUR-REF.supabase.co/rest/v1/profiles?select=*&limit=5" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

Repeat for each table. You want an empty list or a permission error. If real rows come back, a stranger can read them too. Try the same with a POST and a DELETE only on a throwaway test table, never on production data.

Test 3: two accounts, one row

RLS that passes Test 2 can still leak between users. Create accounts A and B. Insert a row as A, note its id, then request that id while logged in as B. If B gets it, your policy checks "authenticated" rather than ownership. The fix is a policy like:

create policy "owner reads own rows" on notes
for select to authenticated
using (auth.uid() = user_id);

Write separate policies for insert, update and delete, and add with check clauses so users cannot write rows that belong to someone else.

Views, storage and grants

Three places where people get caught after RLS looks fine:

• Views. A view runs with its owner's rights by default, which usually skips RLS. On Postgres 15 and later, create it with security_invoker = true, or alter existing views.
• Storage. A policy that says "authenticated users can read bucket X" lets every signed-in user open everyone's files. Store files under a folder named for the user's id and check the folder name in the policy.
• Grants. If an AI "fixes" a permission denied error by turning RLS off or granting everything to anon, undo it. Grant each role only what it needs.

Supabase has said that new tables in the public schema will stop being exposed to the Data API automatically from October 30, 2026. Check their changelog for the exact details. If you hit error 42501 afterwards, add the specific grant and keep RLS on in the same migration.

If a key already leaked

Rotate it in the dashboard, update your server environment, redeploy, and check your Git history as well as the live bundle. Deleting a key from the current code does not remove it from old commits.

Where this stops

These tests only show what a stranger with your public key can do. They do not cover business logic, payment flows or anything behind a login you have not tried by hand. Think of them as a first pass, not a penetration test.

I built DeployVet partly to automate Tests 1 and 2 from the outside, along with exposed files, headers and broken pages. It is free to try and it only looks at the live site, so it will not see Test 3. Run that one yourself.

Fifteen minutes now beats writing the apology email later.