Features
Active Security Testing
With your app running locally, DeployReady can act as a logged-in user and try to break access control — the manual checks you'd otherwise do by hand in Burp or Postman, automated.
What it tests
- Broken object-level authorization (IDOR/BOLA)— swaps resource ids to see whether you can read another user's data.
- Broken tenant isolation — swaps
org_id/tenant to see whether you can reach another tenant's records. - Privilege escalation — forges a
role: adminclaim and checks whether a forbidden route opens up. - Unverified JWTs — checks whether the server accepts a forged
alg:nonetoken (i.e. it never verifies signatures).
How it works
Start your app locally and give DeployReady a token for a logged-in test user. It replays your own authenticated requests with a tampered identity— a swapped id, a different tenant, an escalated role — and checks whether the server wrongly returns the data. Add a second user's token with --token-b to prove tenant and object isolation between two real identities.
terminal
# Act as one user; add a second to test isolation between them
npx deployready@latest analyze . --active --token "<your-JWT>" --token-b "<second-user-JWT>"Getting your token
Run --active without a token and DeployReady prints step-by-step instructions. In short:
- Log in to your app in a browser as a test user.
- Open DevTools (F12) and go to the Network tab.
- Click a request to your API and copy the long string after "Authorization: Bearer …".
- No Authorization header? Check Application/Storage → Local Storage or Cookies for
token/access_token/jwt.
Tokens expire
If you start seeing
401s mid-scan, grab a fresh token and run again.Safe by construction
Active testing is opt-in (only runs with
--active) and asks for confirmation, only targets your loopback app — never a remote host — and is GET-only, so it never writes or mutates data. Run it against local or staging environments you own, not production.Active Security Testing — Overview
Video coming soon
Coming soon.