Verify authorization across users, roles, and tenants.
Define expected access by user, role, and tenant. VardrSec compares those rules against real API behavior and reports mismatches with request and response evidence.
What "write the rules down" looks like
A real VardrGate policy. You state how an endpoint should treat each caller; VardrGate runs the request as every one of them and reports where behavior disagrees, with request and response evidence.
api:
endpoint: GET /users/{user_id}/profile
owner: identity:owner
resource:
type: user_profile
id_param: user_id
tenant_field: tenant_id
expect:
owner: allow
other_user: deny
anonymous: deny
response:
deny_status: [401, 403, 404]
sensitive_fields:
forbidden_for:
- other_user
- anonymousWhat it catches
- potential_bola — a non-owner reached an identified object
- cross_tenant_access — an identity from another tenant got through
- missing_authentication — an anonymous caller reached a protected resource
- sensitive_data_exposure — a caller saw fields it must not (evidence names the fields, never the values)
vardrgate run --job job.json --out result.jsonThe Tools
Built and maintained in the open. Read the code, run it, tell me what's wrong with it.
VardrGate
- Purpose
- Verifies API authorization against a declared policy
- How it works
- Replays one request as every identity and compares the result to the policy
- Why it matters
- Runs in CI, so authorization is tested on every commit
VardrMap
- Purpose
- Untracked assets, unanswered testing hypotheses, and incomplete assessment coverage
- How it works
- Keeps scope, assets, hypotheses, evidence, and findings in one workspace
- Why it matters
- Tracks what has already been tested, not just what exists
VardrRunner
- Purpose
- Executes security workflows locally
- How it works
- Claims queued jobs, runs them locally, and streams results back
- Why it matters
- Credentials, scan traffic, and tool execution remain on your machine
Who's behind this
VardrSec is built by Jorge Aquino, a software engineer focused on broken access control and practical security tooling. His background in the Marine Corps and emergency services shaped a bias toward clear scope, reproducible evidence, and systems that fail safely.
Security testing requires written authorization and a defined scope. Scope allowlists are compiled into the tools rather than left to memory.
Read the longer version →Focus
Authorization is the through-line. Everything here comes back to whether the right caller reached the right resource.
Application & API security
Manual testing of authorization logic, business logic, and injection paths, with reproducible evidence for every reported finding.
Authorization design review
Reviewing a permissions model while it is still cheap to change, and turning the intended rules into something a machine can test.
Security tooling
Building and maintaining the open-source tools above, and helping teams wire authorization testing into a pipeline they already run.
Working on something that needs a second pair of eyes?
Whether it's a question about one of the tools, an authorization design you're unsure about, or a review you want scoped—tell me what you're building. If I'm not the right fit, I'll say so and point you somewhere better.