Security Scan — All 19 Checks Documented

What it checks

Verifies that your site serves content over HTTPS (TLS/SSL) rather than plain HTTP.

How it works

Checks whether the URL resolves to an HTTPS endpoint and that the TLS handshake completes successfully.

Why it matters

HTTP connections are unencrypted — anyone on the network can intercept credentials, session tokens, and user data. All modern sites must use HTTPS.

What it checks

Checks that plain HTTP requests are automatically redirected to HTTPS.

How it works

Makes a request to the HTTP version of your URL and checks for a 301 or 302 redirect to the HTTPS version.

Why it matters

Without an HTTP redirect, users who type your domain without 'https://' will be served insecure content. Search engines and AI crawlers also expect consistent HTTPS handling.

What it checks

Checks for the Strict-Transport-Security response header.

How it works

Inspects the HTTP response headers for Strict-Transport-Security with a non-zero max-age value.

Why it matters

HSTS tells browsers to always use HTTPS for your domain, even if a user manually types http://. It prevents SSL stripping attacks and is required for some compliance frameworks.

What it checks

Checks for HTTP resources (images, scripts, stylesheets) loaded on an HTTPS page.

How it works

Parses the page HTML for resource URLs beginning with http:// while the page is served over HTTPS.

Why it matters

Mixed content degrades security by loading some resources insecurely. Browsers block active mixed content (scripts, iframes) and warn on passive mixed content (images). It also causes browser security warnings.

What it checks

Checks for a Content-Security-Policy header in HTTP responses.

How it works

Inspects response headers for Content-Security-Policy or Content-Security-Policy-Report-Only.

Why it matters

CSP is the most powerful protection against Cross-Site Scripting (XSS) attacks. It restricts which scripts, styles, and resources can be loaded on your page. Missing CSP is one of the most commonly flagged issues in security audits.

What it checks

Checks for the X-Frame-Options header.

How it works

Inspects response headers for X-Frame-Options with value DENY or SAMEORIGIN.

Why it matters

Without this header, your site can be embedded in an iframe by any domain — enabling clickjacking attacks where attackers trick users into clicking hidden buttons on your page.

What it checks

Checks for the X-Content-Type-Options: nosniff header.

How it works

Inspects response headers for X-Content-Type-Options.

Why it matters

Prevents browsers from MIME-sniffing responses — treating a text file as executable JavaScript, for example. This prevents certain content injection attacks.

What it checks

Checks for a Referrer-Policy header.

How it works

Inspects response headers for Referrer-Policy.

Why it matters

Controls how much referrer information is sent when users navigate from your site. Without it, the browser default may leak sensitive URL path information to third-party sites.

What it checks

Checks for a Permissions-Policy header.

How it works

Inspects response headers for Permissions-Policy (previously Feature-Policy).

Why it matters

Controls access to browser features (camera, microphone, geolocation, etc.) for your page and embedded iframes. Prevents malicious third-party scripts from accessing features your site doesn't use.

What it checks

Checks whether your .env file is publicly accessible at /.env.

How it works

Makes a request to [yourdomain]/.env and checks for a 200 response with key=value content patterns.

Why it matters

.env files contain your most sensitive secrets: database passwords, API keys, JWT secrets, payment processor keys. If publicly accessible, any attacker can steal all of them with a single GET request.

What it checks

Checks whether your .git directory is publicly accessible at /.git/.

How it works

Makes a request to [yourdomain]/.git/HEAD and checks for a recognizable git ref response.

Why it matters

An exposed .git directory allows attackers to reconstruct your entire source code — including all secrets ever committed to the repo, deleted files, and full commit history. This is one of the most severe possible exposures.

What it checks

Checks whether JavaScript source map files are publicly accessible in production.

How it works

Checks response headers for X-SourceMap or SourceMap headers, and scans JS files for //# sourceMappingURL comments pointing to .map files.

Why it matters

Source maps expose your original, unminified source code — including file names, code comments, and sometimes environment variables set in code. They're useful in development but should not be deployed to production.

What it checks

Checks for publicly accessible configuration files at common paths.

How it works

Probes a list of common sensitive file paths: /.env.production, /.env.local, /config.json, /wp-config.php, /credentials.json, and others.

Why it matters

Misconfigured deployments sometimes accidentally expose configuration files that contain secrets or infrastructure details.

What it checks

Scans your page's HTML and all linked JavaScript bundle files for 17 known API key and secret patterns.

How it works

Fetches your homepage HTML and all JavaScript bundle files referenced in it (<script src='...'>). Scans the full content of each file against 17 regex patterns for known secret formats.

Why it matters

This is the most common critical vulnerability in AI-built apps. When developers use Cursor, Claude, or ChatGPT to write code, AI assistants sometimes generate code that references API keys directly in client-side files. These keys end up in your bundled JavaScript and are publicly visible to anyone who visits your site — and to automated scanners.

API key patterns detected (17)

What it checks

Checks whether admin panels, database interfaces, or debug endpoints are publicly accessible.

How it works

Probes common admin paths: /admin, /phpmyadmin, /graphql (with introspection enabled), /api/graphql, /_debug, /debug, and similar paths.

Why it matters

Exposed admin panels are a high-value target for attackers. GraphQL introspection enabled in production leaks your entire API schema. Debug interfaces can expose stack traces, environment variables, and internal state.

What it checks

Checks for Access-Control-Allow-Origin: * in API response headers.

How it works

Makes a cross-origin request to your domain and checks the Access-Control-Allow-Origin header in the response.

Why it matters

CORS wildcard (*) allows any website to make authenticated cross-origin requests to your API. This can allow malicious sites to exfiltrate user data from your API using a victim's browser session.

What it checks

Checks that session and auth cookies have Secure and HttpOnly flags set.

How it works

Inspects Set-Cookie headers in HTTP responses for the presence of Secure and HttpOnly flags.

Why it matters

Without the Secure flag, cookies can be sent over HTTP. Without HttpOnly, cookies are accessible via JavaScript and can be stolen by XSS attacks. Both are required for cookies that carry authentication tokens.

What it checks

Checks for the X-Powered-By header that discloses your technology stack.

How it works

Inspects response headers for X-Powered-By.

Why it matters

Headers like X-Powered-By: Express or X-Powered-By: Next.js tell attackers which framework you're running, enabling targeted exploitation of known framework vulnerabilities. It's low-cost to remove and eliminates a free reconnaissance signal.

What it checks

Checks for the presence of a Web Application Firewall (WAF) and rate limiting headers.

How it works

Checks response headers for known WAF signatures: CF-Ray (Cloudflare), x-amzn-RequestId (AWS WAF), X-Sucuri-ID, X-Akamai-*, Fastly-*, Imperva-*. Also checks for RateLimit-* and X-RateLimit-* headers.

Why it matters

This is an informational check — a passing result means your site has WAF and rate limiting protection, which reduces your attack surface. A failing result is a recommendation to add these protections rather than a critical vulnerability.