Findings
Ordered by proof state, then by severity and how far the attack reaches. Each finding carries its full plain-English explanation and the reach it proves.
-
default credentials
Default credentials accepted at /admin/login
An account is still on its factory password.
What we proved. We tried a short list of factory passwords on your login and one was accepted. We confirmed it by carrying the session it handed us to a page an anonymous visitor cannot open, then stopped.
What it is. An account is still on its factory password: admin/admin, or a default database, router or device login that was never changed.
The risk. The attacker simply logs in. No exploit, no cleverness. They are now you.
How likely. Routine. Default passwords are public and tried first.
What it reaches. Control of whatever the account runs, up to Root on a server or device login.
Why the severity. Critical on an admin or infrastructure account. High elsewhere.
-
path traversal
Path traversal via ?file= reads arbitrary files
A page that serves files lets a visitor step out of the intended folder.
What we proved. We asked for a path outside the intended folder and the response contained the system password file, /etc/passwd. We read that one file and stopped.
What it is. A page that serves files lets a visitor step out of the intended folder by asking for ../../ paths.
The risk. They read files off the server that were never meant to be public: source code, configuration, keys, the system password file.
How likely. Routine to test. Reliable when present.
What it reaches. Data, and the makings of Control. Config and source often carry the keys to everything else.
Why the severity. Critical. It reads files off the server, and the files it reads carry the keys to everything else.
-
sensitive file exposure
Sensitive file exposed: /.env
Files that were meant to be private are readable straight from the web.
What we proved. We asked for the file, having first checked that your server does not answer every unknown path with the same page. We call it read only when what came back matches the format that path claims to be.
What it is. A database backup, a .env config, a .git folder, or an open directory that lists everything in it, all readable from the open web.
The risk. An attacker downloads them and reads what is inside. A config file or a backup often holds passwords, API keys and customer records in a single file.
How likely. Routine. Automated scanners check the common paths within seconds of finding your site.
What it reaches. Data. Where the file holds a live key, that key can hand over Control or the database with no further work.
Why the severity. High. Critical when the exposed file contains a secret or personal data.
-
crlf injection
HTTP response splitting via ?next= parameter
Visitor input lands in a response header without being cleaned.
What we proved. We put an encoded line break in a parameter and a header of our own came back in your server’s response.
What it is. Input from a visitor lands in a server response header without being cleaned, letting an attacker insert new lines and forge extra headers.
The risk. They can plant a poisoned response in a shared cache that is then served to other visitors, set their own cookies, or trigger a cross-site script.
How likely. Situational to find. Effective when present.
What it reaches. Foothold, and Control of a visitor’s session through the chained script.
Why the severity. High. We watched our own header come back, so this one is proven, and a shared cache spreads whatever is injected next.
-
sql injection
Database error on injected quote in "id" at /product
Your site builds a database query out of something a visitor typed.
What we proved. We added a single quote to a parameter and your page came back with a database error. That is the signature of an injection; we did not push on it and we read no data.
What it is. Your site builds a database query out of something a visitor typed, so an attacker can rewrite the query and ask the database whatever they like.
The risk. Where the injection is real, an attacker reads and changes the database directly: customers, orders, password hashes.
How likely. Routine to test. Where it is present it is usually fully exploitable.
What it reaches. Data, meaning the database sitting behind that page.
Why the severity. Critical when it is real, because it is direct access to everything you store.
-
cross-site scripting
Reflected, unescaped form input "q" at /search
Your page shows text from a visitor without cleaning it first.
What we proved. We put a harmless marker in a parameter and found it echoed back into the page unescaped. No script of ours ran, and this check only finds the reflected kind.
What it is. Your page shows text from a visitor without cleaning it, so an attacker can make the page run their code inside someone else’s browser.
The risk. Their code runs as your visitor. It can take the session cookie and use the account, capture what they type into a form, or quietly change what the page does. Aimed at an admin, it takes over the admin.
How likely. Likely. One of the most common holes on the web and easy to test for. This kind needs the victim to open a link the attacker built.
What it reaches. Data belonging to the visitor who opens that link: their session, and whatever their account can see. It reaches Control where the visitor who opens it is an admin.
Why the severity. High where the reflection lands on a page your customers use. Critical on an admin console or a payment page.
-
cookie flags
A cookie is set without Secure, SameSite
A cookie is set without its safety flags.
What we proved. We loaded your home page as an anonymous visitor and read the flags on the cookies it set. We never logged in, so we cannot tell you which of your cookies carries a session.
What it is. A cookie your site sets is missing its safety flags (Secure, HttpOnly, SameSite), so a script can read it or it travels over plain HTTP.
The risk. Where the cookie in question carries a login, an attacker who can run a script on your page or watch the network takes it and uses that account.
How likely. Situational. It needs a second hole, an injected script or an insecure link, to cash in.
What it reaches. Nothing on its own. It reaches Control of an account where the cookie missing the flag is the one carrying a login and something else can read it.
Why the severity. Low. High on the session cookie of an admin.
-
security headers
Missing security headers: CSP, HSTS, Referrer-Policy
Your server does not send the browser its safety instructions.
What we proved. We read the response headers your server sends and listed the ones that are absent. That is the whole check.
What it is. Content-Security-Policy, HSTS, X-Frame-Options and their neighbours are missing. These headers tell the browser what to trust.
The risk. An attacker has more room to run a script in your visitor’s browser, to frame your site inside theirs and trick a click, or to drop a visitor onto plain HTTP and read the traffic.
How likely. Routine to spot. On its own it rarely lets anyone in. What it does is make every other hole easier and more reliable.
What it reaches. Nothing on its own. It widens an injected script or a session theft once another hole opens the door.
Why the severity. Low alone. We raise it when a real script-injection hole or a login sits behind the missing header.
-
source map exposed
Source map exposed: /js/app.js.map
The source maps for your minified JavaScript are published alongside it.
What we proved. We downloaded the .map file next to your bundle and it parsed as a version 3 source map.
What it is. The source maps that translate your minified JavaScript back into readable code are published alongside it.
The risk. An attacker downloads your original front-end source, comments and all, and reads it for endpoints, keys and logic to attack.
How likely. Routine to pull when present.
What it reaches. Recon, occasionally Data when the recovered source carries a secret.
Why the severity. Low. Raised when the recovered code leaks a key.
-
secret exposure
Possible AWS access key id exposed in client code (/js/app.js)
A key is sitting in the code your site sends to browsers, where anyone can read it.
What we saw. We matched a key pattern in the code your site serves to browsers. We never tried the key against the service it belongs to, so we cannot tell you whether it still works.
What it is. A key is sitting in the code your site sends to browsers: an API key, a token, a password baked into the JavaScript.
The risk. Whatever the key opens is open to whoever reads the page. A payment key, a cloud key or a database token in the page is a direct line to money, infrastructure or data.
How likely. Routine. The file is public and scanners read it automatically.
What it would reach. Data, Control or Root, set entirely by what the key opens. Some keys belong in the page: a browser key for maps or analytics is designed to ship, and is held in place by a restriction on which domain may use it.
Why the severity. High for a server-side credential. Low for a browser key that is meant to be public, where the thing to check is its domain restriction. Critical once a key is confirmed live.
-
cors misconfiguration
Permissive CORS (reflects arbitrary Origin)
Your server tells browsers that any website may read its responses.
What we saw. We asked with an Origin header naming a site we do not own, and your server told the browser that site may read the response. We read no private data through it.
What it is. Your server echoes back whatever Origin a page claims and tells the browser that page is allowed to read the response, sometimes with the visitor’s login attached.
The risk. A page the attacker controls can call your site as your logged-in customer. Where an endpoint behind that header returns private data, their page reads it back: account details, order history, saved addresses.
How likely. Likely where the header is wrong. It needs the victim to visit the attacker’s page first.
What it would reach. Foothold: the attacker’s page gets to talk to your site as your visitor. It reaches Data where an endpoint behind that header returns personal records, which we have not tested.
Why the severity. Medium. High when the response is allowed to carry the visitor’s credentials.
-
cross-site request forgery
POST form without an anti-CSRF token at /account/update
A form accepts an action without proving the request came from your own page.
What we saw. We read the HTML of a POST form and saw no token field in it. This one is a heuristic: an app can carry the token in a header or a cookie our crawl cannot see, so check the form before you act on it.
What it is. A form or action runs without a token proving the request came from your own site, so another page can submit it on a logged-in visitor’s behalf.
The risk. An attacker’s page can make your visitor change their email, their password or their saved details without meaning to.
How likely. Situational. It needs the victim to be logged in and to open the attacker’s page.
What it would reach. Nothing on its own, on this evidence. It reaches Control of the account where the unprotected action is sensitive and the token really is absent.
Why the severity. Medium, set by what the unprotected action does.
-
api surface
API endpoints discovered: /api, /openapi.json
Endpoints answer requests directly, outside the pages of your site.
What we saw. We requested the path and it answered with JSON. We did not test whether it checks who is asking, and several of these are public by design.
What it is. API endpoints answer requests directly: a documented one, an old version, a health route, a debug route.
The risk. Each one is somewhere an attacker can aim without going through your pages. Where an endpoint answers without checking who is asking, they read or change data the website itself would never let them touch.
How likely. Likely to be found. Automated tools sweep the common paths in seconds.
What it would reach. Recon. We know these answer. Whether they check who is asking is the next test, and that is where the reach is decided.
Why the severity. Info. A schema file or a health check is meant to be there. The severity comes from what an endpoint does once someone tests it.
How we ran this, and what the words mean
You proved you control northwind-shopfront.example before we started, and we scanned only that server. The whole assessment is non-destructive: we read, we probe, and we stop the moment a hole is proven. We do not extract your data, change it, or leave anything behind.
Every finding is either a potential hole, a confirmed one, or one we exploited. We keep those three words separate on purpose:
potentialWe saw the signature of the hole. We did not push on it. confirmedWe proved it is real and reachable, without touching your data. exploitedWe performed the attack ourselves, non-destructively, and captured what it gave up.
Behind the scan, an autonomous attacker probes your site and a separate frontier model reviews every claim against the raw evidence before it reaches this page. That review can confirm a finding; only our own check can mark one exploited, and it does that solely when it performed the attack and captured what came back. Where you see exploited, it happened.
Appendix
The parameters of this run, and the full set of checks the scan covers.
Scan parameters
target northwind-shopfront.example
scan id sample-0000-0000-0000-000000000000
started 13 August 2026
ownership verified before the scan started
mode non-destructive, single origin
What we check for
- security headers
- The browser safety instructions your server should send.
- sensitive file exposure
- Private files and open directories readable from the web.
- admin surface
- An admin login or control panel reachable from the open internet.
- cross-site scripting
- Pages that run a visitor’s code in someone else’s browser.
- sql injection
- Visitor input that rewrites your database queries.
- template injection
- Input that runs as code inside your page templates.
- cors misconfiguration
- A server that lets any website read its responses.
- open redirect
- A link on your domain that forwards visitors anywhere.
- path traversal
- Requests that step out of a folder to read other files.
- info disclosure
- Error pages that leak how your site is built.
- cookie flags
- Cookies set without their safety flags.
- api surface
- Endpoints that answer requests directly, outside your pages.
- graphql introspection
- A GraphQL API that hands out its full schema.
- prompt injection
- An AI feature that obeys instructions hidden in its input.
- injected instructions in your content
- Text on one of your pages that gives instructions to automated readers.
- http methods
- Unsafe methods like TRACE or open write verbs.
- crlf injection
- Input that forges extra response headers.
- host header injection
- A trusted Host header an attacker can set.
- source map exposed
- Published maps that rebuild your front-end source.
- secret exposure
- Keys and passwords left in the code your site sends to browsers.
- default credentials
- Accounts still on their factory password.
- cross-site request forgery
- A form that runs without proving the request came from your own site.
|