You shipped it in a weekend.
Who else can read it?

SecScan is an automated black-box security scanner for web applications. You give it a URL for a site you own or are authorised to test, and it runs 213 security checks against the live application — security headers, TLS, cookie flags, exposed configuration files, leaked credentials, injection, and access control — then returns a plain-English report with a letter grade from A to F and a numeric risk score. Scans run at secscan.us; the reference documentation is at secscan.info.

No. SecScan is an automated scanner and does not replace a manual penetration test. It finds the classes of problem that are reliably detectable from outside an application — misconfiguration, exposure, missing controls and known-vulnerable components — but it cannot reason about business logic the way a human tester can.

Its passive checks do not — they observe only what an ordinary visitor sees. Its active checks do send real probe traffic, including injection payloads and path-traversal attempts, so they run only against domains whose ownership you have proven with a DNS TXT record or a well-known file. There is no denial-of-service testing, no credential brute-forcing and no destructive requests.

It runs 213 checks across 47 modules: security headers including CSP and HSTS, TLS versions, cipher suites and certificate validity (checked by SecScan itself, with no outside grading service), cookie Secure/HttpOnly/SameSite flags, CORS misconfiguration, 81 sensitive paths such as .env files and .git directories, 35 credential patterns in JavaScript bundles, Supabase and Firebase access rules, Next.js __NEXT_DATA__ leakage, JWT weaknesses, exposed source maps and API documentation, known-CVE component versions, DNS and email authentication records, and, when you name a GitHub repository, its source files (committed secrets, Supabase migrations, CI configuration, risky code patterns and vulnerable dependencies), and — on verified domains — reflected XSS, SQL injection, path traversal, IDOR and broken function-level authorisation.

Every actionable finding is confirmed behaviourally rather than inferred from the presence of a response. Header gaps are re-fetched before they are reported, candidate paths are checked against the site’s own catch-all handler so a single-page app’s fallback route cannot look like an exposed file, and public-by-design keys are excluded from credential matching. The scanner is regularly run against well-secured sites where the correct answer is known in advance, and every actionable finding is checked by hand.

secscan.us is the scanner itself — where you sign in, run scans and read reports. secscan.info is the reference documentation: what each check looks for, what each finding means, and how to fix it. They are one product under one publisher.