Web app security scanner: every check we run, free

Greenlight's free web app security scanner runs automated, read-only checks on any website or web app. Below is every check it runs, plus a checklist for the things an outside scan can't see. Start a scan from our home page.

1. HTTPS and SSL

Every page loads over https://, and http:// redirects to it.
The certificate is valid, not expired, and matches your domain (including www if you use it).
No "mixed content": images, scripts, and forms also use HTTPS.

2. Security headers

Headers tell browsers how to protect your visitors. Check for Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, a frame-ancestors rule or X-Frame-Options, and Referrer-Policy. Our security headers checker explains each one.

3. Exposed API keys and secrets

Open your site, view the page source and JavaScript files, and look for anything that looks like a secret key or password.
Publishable keys are designed to be public. Secret keys (payment, email, AI, database admin) must stay on the server.
Check that files like .env or .git aren't reachable from the web.
If a secret key was ever public, rotate it, even if you removed it later.

4. Admin and login pages

Admin, dashboard, and staging pages require a login, not just an unlisted URL.
Logins use strong passwords or a trusted sign-in provider, and two-factor for admins.
Error pages don't show stack traces, file paths, or debug info.

5. Data access rules

The most serious problems are usually ones an outside scan can't fully see: can a logged-in user read or change someone else's data? Test with two accounts. If your app uses Supabase, see whether the anon key is safe to expose and Supabase RLS for beginners.

Apps built with AI tools

If you built your app with an AI coding tool, run this same checklist. These tools move fast, so keys ending up in front-end code and missing access rules are worth checking twice.

Pre-launch checklist

HTTPS everywhere, valid certificate, HTTP redirects to HTTPS.
Security headers set.
No secret keys in public pages or files; leaked keys rotated.
Admin and staging pages behind a login.
Users can only see and change their own data (test with two accounts).
Backups exist and you know how to restore them.
Dependencies and plugins up to date.

Everything the Greenlight scan checks

Our free scan runs these automated, read-only checks on your site's main address and the public files it loads:

HTTPS: the site loads over HTTPS, HTTP redirects to HTTPS, the certificate is valid, trusted, and not expired (with a complete chain), old TLS 1.0/1.1 isn't accepted, and the page doesn't load content over plain HTTP.
Security headers: HSTS (and whether it covers subdomains), Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, clickjacking protection (X-Frame-Options or frame-ancestors), cookie security flags, and an X-Powered-By header that names your stack.
Exposed secrets: secret keys in your public code, including Stripe, OpenAI, Anthropic, AWS, Google, GitHub, Twilio, Resend, SendGrid, Groq, xAI, Slack, and Mapbox keys, private key blocks, and Supabase service_role or secret keys.
Exposed files: .env and .env.local, the .git folder, public source maps, and common backup and config files (such as database dumps, site archives, .env.production, .npmrc, and phpinfo.php).
API routes and CORS: common debug and config routes (such as /api/debug and /api/env) that are open or return user-like records, and CORS settings that let other websites make requests to your app.
Outdated libraries: old versions of jQuery, Bootstrap, lodash, and AngularJS with known public issues.
Duplicate copies: whether your app may also be live on a vercel.app address.
Supabase (if detected): how your tables answer the public key (counts only in the free scan), possible write access, sensitive-looking functions, and tables likely missing a grant. We never send writes.
Email domain: SPF and DMARC records.
Search and accessibility basics: page title, meta description, canonical link, noindex, sitemap, page language, mobile viewport, image alt text, and form labels.

What the Fix Report adds (coming soon)

The $19 Fix Report isn't on sale yet. It's planned to include:

Table-by-table detail: if we detect Supabase, each table by name with its result (the free scan shows counts only)
Every finding explained in plain English, with a fix for each issue
A suggested fix order, starting with the most urgent
One combined “fix everything” prompt to paste into your AI builder, in a general version plus versions for Lovable, Bolt, Cursor, Replit, Windsurf, Claude Code, v0, OpenAI Codex and Grok Bot
If we detect Supabase: a checklist for its Oct 30, 2026 change, with the GRANT lines new tables need, paired with Row Level Security

Other free tools

The security headers checker explains each header above. The meme coin scanner checks a Solana token's mint authority, freeze authority, Token-2022 extensions, liquidity or bonding curve, top-10 holder share, and token age.

Run the outside checks for free

Our free scan runs the checks listed above on your public pages. It's automated, read-only, and limited, and a clean result doesn't mean your site is secure. It isn't a security audit.

Scan your site free

FAQ

What does a web app security scanner check?
Greenlight's scanner checks what it can see from outside: HTTPS and the certificate, security headers and cookie flags, secret keys in public code, exposed files such as .env and .git, open debug API routes, risky CORS settings, outdated JavaScript libraries, and, if detected, how Supabase tables answer the public key.

How do I check if a website is secure?
Start with the basics you can see from outside: the site loads only over HTTPS with a valid certificate, it sends security headers, no secret API keys appear in its pages or JavaScript files, and admin or login pages are protected. Then check access rules on your server and database, which an outside check can't fully see.

Does HTTPS mean a website is safe?
No. HTTPS encrypts traffic between the visitor and the server, but it says nothing about whether the site leaks keys, has weak logins, or lets users read data they shouldn't.

Which security headers should a website send?
Common ones are Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, a frame-ancestors rule or X-Frame-Options, and Referrer-Policy. Which values fit depends on your site.

How can I tell if my API keys are exposed?
Search your public HTML and JavaScript bundles for key-like strings. Publishable keys (such as a Stripe publishable key or a Supabase anon key) are meant to be public; secret keys never are. If a secret key was ever public, rotate it.

Is this a free website vulnerability scanner?
The scan is free and looks for common, publicly visible problems. It is limited: it checks your main address and the public files it loads, never sends writes, and a clean result doesn't mean a site is secure.

Is a free online scan a full security audit?
No. An automated outside scan checks public pages and files only. A clean result doesn't mean a site is secure. For apps handling sensitive data, get a professional review.

How often should I run a website security check?
Before launch, after big changes such as a new feature, a new host, or new third-party scripts, and on a regular schedule after that.

Greenlight My App is independent and not affiliated with or endorsed by any product named here. Educational, not professional security advice.

Get the next change before it bites

Greenlight tips and new blog posts: short, practical notes when Supabase, Lovable, Bolt, Cursor or another tool you build with changes something that affects your app, plus what to check. About twice a month.

We'll send a confirmation email first. Unsubscribe anytime. Privacy. Greenlight My App is independent and not affiliated with or endorsed by Supabase, Lovable, Bolt, Cursor or any other tool we mention.