Website security scanner that shows its evidence

What it checks

Twenty-seven checks across the parts of a site an attacker sees first. Each finding is marked as observed (seen directly in the response), inferred (a version read from a file name, a session cookie recognised by its name) or worth a look.

• Transport: plain HTTP, HTTP not redirecting to HTTPS, untrusted or expiring certificates, missing or short HSTS
• Content-Security-Policy: missing, report-only, unsafe-inline, unsafe-eval, wildcard script sources, missing object-src and base-uri
• Clickjacking protection, X-Content-Type-Options, Referrer-Policy, server version banners
• Cookies without Secure, and session cookies without HttpOnly or SameSite
• Mixed content, third-party scripts without Subresource Integrity, password forms over HTTP
• Error traces in pages, secret keys in HTML and JavaScript bundles, public source maps
• Outdated JavaScript libraries with known vulnerabilities, checked against the OSV database

Built for modern, bundled sites

Most sites ship one hashed bundle, not a jquery.js you can read the version off. RepoVerse reads library versions out of minified code, licence comments wherever the bundler put them, webpack's separate licence files and published source maps, and it follows the chunks a bundle loads later. Against real Vite and webpack builds of known versions it identified eight libraries out of nine.

Passive by design

It loads only what a visitor loads: the page, a few more pages on the same site, the site's own scripts, robots.txt and security.txt. No attack payloads, no guessed paths, no login attempts — which is why it is safe to run against any public site, including ones you do not own. robots.txt is obeyed, every request identifies itself, and each review is capped in requests and time.

What it does not do

It is not a penetration test. It does not try to break in, and it cannot see anything behind a login or inside the server. Pages are read as served, without running their JavaScript, so links that only appear after a single-page app renders are not followed. Scanning a website into a 3D map is free; the security review is part of Pro.

What it checks

• HighSite is served over plain HTTP

  Everything between the visitor and the server — pages, form fields, cookies — can be read and changed by anyone on the network path: public Wi-Fi, an ISP, a compromised router.

  website · CWE-319

• HighTLS certificate is not trusted

  Browsers show a full-page warning. Visitors who click through can no longer tell your server from an impostor's, which is exactly what an interception attack needs.

  website · CWE-295

• ModerateNo HSTS header

  Without `Strict-Transport-Security` the browser will still try plain HTTP for typed addresses and old links, which leaves room for an SSL-stripping attack on the first request.

  website · CWE-319

• ModerateNo Content-Security-Policy

  If any page has an injection bug, the injected script runs with nothing to stop it — CSP is the layer that limits what one XSS can do.

  website · CWE-693

• ModerateCSP allows inline scripts

  `'unsafe-inline'` in `script-src` lets injected `<script>` tags and event handlers run, which is the main thing a CSP is there to stop.

  website · CWE-79

• ModeratePages can be framed by any site

  Another site can load your pages in an invisible frame and trick a logged-in visitor into clicking buttons they cannot see — changing settings, confirming payments.

  website · CWE-1021

• ModerateCookie set without the Secure flag

  The browser will also send this cookie over plain HTTP, where anyone on the network can read it.

  website · CWE-614

• ModerateSession cookie readable by page scripts

  Without `HttpOnly`, one injected script can read the session cookie and send it away, handing over the logged-in account.

  website · CWE-1004

• ModerateHTTPS page loads resources over HTTP

  Browsers block insecure scripts, styles and frames on an HTTPS page, so those parts break; where they do load (images, media) they can be swapped on the network.

  website · CWE-319

• LowThird-party script loaded without integrity check

  If the CDN or the other site is compromised, the script it serves runs on your pages with full access — the supply-chain path behind several card-skimming attacks.

  website · CWE-353

• HighFront-end library with known vulnerabilities

  The page ships a library version that has published advisories; the vulnerable code runs in every visitor's browser.

  website · CWE-1104

• CriticalSecret key visible in a public page or script

  Anyone who opens the page source has the key and can use it with your account's permissions — these are scraped automatically.

  website · CWE-798

• LowSource maps are public

  Anyone can download the original, unminified source — comments, internal API routes, feature flags and code paths you did not mean to publish — which makes the next attack easier to plan.

  website · CWE-540

• ModeratePage shows an error trace

  Stack traces and database errors reveal file paths, framework versions and query structure — a map for the next attack.

  website · CWE-209

Questions

Is it safe to scan a website I do not own?

The review only requests what any browser visiting the site requests — pages, scripts and public files — and sends no attack traffic, so it is as safe as opening the site. Active testing such as fuzzing or login attempts needs the owner's permission and is not something RepoVerse does.

What does a website security scan check first?

HTTPS and HSTS, the Content-Security-Policy, frame protection and cookie flags, because those decide how much damage a single bug can do. Then the page content: mixed content, unpinned third-party scripts, exposed keys and outdated libraries.

Can it find vulnerable JavaScript libraries in a minified bundle?

Yes, in most cases. Versions are read from version strings that survive minification next to code unique to each library, from licence banners and from source maps. Libraries that carry no version anywhere in their code cannot be read this way, and the report says where each version came from.

How is this different from a security headers check?

Headers are one part. The scanner also reads cookies, TLS, redirects, the page HTML and its scripts, so it finds exposed keys, mixed content and vulnerable libraries that a headers-only check cannot see.

Related

• Security headers checker with a fix for every gapCheck a site's HTTP security headers — Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy — and get the exact line to add for each gap.
• Find vulnerable JavaScript libraries on a live websiteFind outdated, vulnerable JavaScript libraries on any website — jQuery, lodash, Bootstrap, moment, DOMPurify, Next.js — even inside minified Vite and webpack bundles.
• Content Security Policy: writing one that actually protectsWrite a Content-Security-Policy that actually stops XSS: why unsafe-inline, unsafe-eval and wildcard sources defeat it, nonces and strict-dynamic, and a policy to start from.
• HTTPS and HSTS: closing the plain-HTTP gapWhy every site needs HTTPS, a 301 redirect from HTTP and a Strict-Transport-Security header (CWE-319), what max-age to use, and how to avoid mixed content.
• Clickjacking: stolen clicks through an invisible frameHow clickjacking (CWE-1021) hides your page in an invisible frame to steal clicks, and the two headers — CSP frame-ancestors and X-Frame-Options — that prevent it.