Learn
Start here
Six tutorials, in the order you will hit them: install the thing, run a scan, understand what came back, then keep it running. Underneath, the reference for what each finding means. The docs are the full account of everything both of them skip.
Tutorials
Each one is a numbered path with the commands and the screens, and every step says what you should see before the next one makes sense. Do them in order the first time.
- 01 Run your first scan From an empty account to hosts landing in your asset graph. The one thing worth knowing before you start: Crossfyre does not scan from our infrastructure. You enrol a machine you control, and scans leave from your address. About 15 minutes, most of it waiting
- 02 Scan a web application end to end Four workflows against one application, in an order that matters. Each stage writes into the same asset graph, so the vulnerability scan tests endpoints that were actually found rather than paths it guessed at. About 30 minutes for a small application
- 03 Read your findings A scanner hands you a queue, and the work is deciding which few are worth an afternoon. Two numbers do most of that sorting, and they are answering different questions. 10 minutes
- 04 Scan behind a login Most of an application is behind a login, and an unauthenticated scan never sees any of it. This is the single change that most increases what a scan finds. 15 minutes, once per application
- 05 Test for broken access control The worst bugs in an API are usually one user reaching another user's data. A scanner logged in as one identity cannot see them, because the response is a perfectly healthy 200. 20 minutes
- 06 Keep a target monitored A scan is a photograph of a target on one afternoon. Most of what you want to know is what changed since, and that is a different thing to read. 10 minutes to set up, then nothing
What every finding means
A scanner that returns a red mark and no explanation gets used once. This is the reference behind 38 checks: what each finding is, what somebody does with it, and what fixing it actually involves. Nothing here needs an account or a scan you have run.
Exposed files and secrets
29 findingsA web server serving a file nobody linked to is the most common way source code and credentials leak. This page covers the twenty-nine files worth checking for, what an attacker does with each, and the fix. Almost all of them are introduced by a deploy rather than by an attack.
Read the reference →Security headers and CORS
7 findingsSecurity headers are instructions a site sends to the browser about what it is allowed to do with the page. This covers the ones worth having, what their absence permits, and the CORS configuration that quietly turns a read-only API into an account takeover.
Read the reference →Subdomain takeover
2 findingsA subdomain takeover happens when a DNS record still points at a hosting service that no longer has anything on it. Whoever claims that service name next controls what your subdomain serves. The record outliving the service is the entire bug.
Read the reference →Why these three and not everything
They are the exposures a stranger can confirm from the outside, without an account and without touching anything. That makes them the ones worth checking on a schedule, because anyone else can check them too, and the ones most likely to be introduced by a routine deploy rather than by an attack.