BlogPerspective
Attackers don't see findings. They see paths.
A severity score describes a weakness in isolation. An adversary is interested in the third hop, not the first.
· 6 min read
Capability
Attack your applications before attackers do.
Web applications and APIs are not secure because a scanner found nothing critical. They are secure to the extent that an attacker cannot turn their weaknesses into unauthorized access, data exposure, credential theft, or a path deeper into the environment. RedMaw tests applications adversarially to prove what can actually be reached.
The question this answers
What can someone actually do with it?
Each hop validated by successful exploitation
The framing
The security question is not “what is vulnerable?”
What can someone do with it?
A missing authorization check matters because it may expose another customer's data. A leaked secret matters because it may authenticate to a cloud service. A session weakness matters because it may let an attacker become another user. A business-logic weakness matters because it may let someone perform an action the product never intended to allow.
RedMaw moves the conversation from vulnerability presence to exploitability and attacker outcome.
Authentication under attack
Authentication controls often look correct when they are tested only through expected user behavior. Adversarial testing asks whether the surrounding assumptions hold.
The goal is to establish whether a weakness can create real access inside the approved scope, not to note that a control exists.
Authorization fails only when someone tries to cross the boundary.
Authorization flaws are contextual. An endpoint can work perfectly for the intended user and still expose data when an object identifier, role, request sequence or API parameter is manipulated.
Expected
GET /api/customers/4831/invoices
The application correctly returns the user's own invoice.
Adversarial
GET /api/customers/4832/invoices
The important question is what happens when the identifier changes to another customer's.
RedMaw tests whether those trust boundaries actually hold. Instead of reporting that an endpoint may be susceptible to broken object-level authorization, the objective is to validate whether unauthorized access is possible, and to preserve the evidence.
APIs are part of the application, not a separate problem.
Modern products expose much of their business logic through APIs. The important signal is not how many endpoints exist. It is which endpoint behavior can be turned into unauthorized access or material impact.
Business logic does not have a CVE.
Some of the most important application weaknesses are not software defects in the traditional sense. The application may behave exactly as implemented and still allow an attacker to abuse the workflow.
- Manipulating a sequence the application assumes happens in a fixed order
- Changing values the server trusts too much
- Repeating an action that should be one-time
- Crossing a role boundary through an alternate workflow
- Reaching a privileged operation through an unexpected route
A fixed CVE library is not designed to understand every business-specific trust decision. Adversarial validation exists for precisely that gap.
Secrets turn application findings into access.
A secret in a response, configuration file, repository, error message or exposed endpoint changes the meaning of an application weakness. The next question becomes: does the secret work, and what does it unlock?
Where authorized and supported, RedMaw validates credential and secret exposure rather than treating the presence of a string as the final finding. That is how an application issue becomes an attack path.
Comparison
Why this is not a vulnerability scanner
A vulnerability scanner
Broad, deterministic coverage.
It runs a known library of checks against your assets and tells you what resembles a documented weakness. That coverage is genuinely useful. Keep it.
- Reports what might be wrong
- Consistent and repeatable
- Wide surface, shallow depth
RedMaw
Validation of what can be used.
It takes the weakness and attempts to turn it into access within approved scope, then keeps the evidence of what succeeded.
- Proves what is actually reachable
- Evidence a developer can reproduce
- Narrow surface, adversarial depth
The scanner is useful for coverage. RedMaw is useful for proof. Most mature programs should run both.
After the finding
Validated findings enter the RedMaw findings-state layer. They can be pushed to Jira, GitHub Issues, Slack or email with proof and remediation guidance attached.
After the fix, RedMaw re-tests the issue. The finding closes when the exploit no longer works.
Typical questions
What RedMaw is trying to answer here
- Can one user access another user's object or record?
- Can an authentication or session weakness be used to gain access?
- Can an exposed secret authenticate to another system?
- Can an API trust boundary be crossed?
- Can business logic be manipulated into an unauthorized outcome?
What RedMaw tests
Tested adversarially, not inventoried
Each area below is exercised by attempting exploitation within authorized scope, and the result is recorded as evidence.
Authentication
- Login and session controls
- Password-reset behavior
- Token handling and credential exposure
- Authentication-state manipulation
Authorization
- Object-level access control
- Function-level authorization
- Privilege boundaries between roles and tenants
- Parameter and identifier manipulation
Logic and exposure
- Business-logic abuse and workflow bypass
- Reachable administrative functions
- Exposed secrets, keys and tokens
- Unsafe trust assumptions in APIs
Evidence
What proof looks like
A useful application-security finding answers more than “where is the weakness?”. RedMaw evidence is designed to show:
- The affected application, API or endpoint
- The adversarial technique used
- The request or action that succeeded
- The access or data that became reachable
- The user or privilege boundary that was crossed
- The remediation target
- The retest result after the fix
Boundaries
Where this stops
Adversarial testing is only credible when its limits are explicit.
Testing is limited to explicitly authorized applications, APIs, domains, environments and actions.
RedMaw does not treat every suspicious pattern as confirmed exploitability.
It does not replace broad vulnerability scanning.
It does not claim that every application weakness automatically forms a cross-surface attack path.
One platform
This surface is not tested in isolation
The same engine, evidence model and findings state run across all four surfaces.
Technical reference
Related reading
Attack LibraryApplications
BOLA: Broken Object Level Authorization
Authentication proves who is calling. BOLA is what happens when nothing checks what they are allowed to touch.
· 6 min read
Attack LibraryApplications
SSRF to Cloud Metadata
The interesting part is not that the application made an unexpected request. It is where that request could reach.
Attack LibraryApplications
Insecure Deserialization
The defect is not the format. It is that the server trusts attacker-controlled object state.
Attack LibraryApplications
JWT Algorithm Confusion
The token verified. That is not the same as the token being trustworthy.
Attack LibraryApplications
Mass Assignment
The endpoint worked as written. It was written to trust too much.
Attack LibraryApplications
GraphQL Introspection & Batching Abuse
A flexible query language is a flexible attack surface when authorization sits in the wrong layer.
Attack LibraryApplications
Path Traversal to Source Disclosure
Reading a file is minor. Reading the configuration that holds the credentials is not.
Attack LibraryApplications
SQL Injection to Filesystem
The database was the entry point, not the destination.
Attack LibraryApplications
Business-Logic Price Manipulation
No vulnerability class fits. The application did exactly what it was told to do.
Attack LibraryApplications
Race-Condition Double Spend
Both requests were authorized. That was the problem.
Attack LibraryApplications
Subdomain Takeover
The domain still belongs to you. What answers on it may not.
Attack LibrarySaaS & Identity
Service-Account Key Sprawl
Nobody offboards a service account.
Attack LibrarySaaS & Identity
Session-Token Replay
Authentication already happened. The token is the proof, and proof can be copied.
BlogPerspective
The catalogue is not the boundary of the attack surface
A weakness does not start working on the day it gets an identifier. It was already working. The identifier is just when defenders found out.
· 5 min read
BlogRemediation
A security ticket is not proof that a vulnerability is fixed
Done means the task changed state. Fixed means the security condition changed state.
· 3 min read
GuidesGuide
Answering a long enterprise security questionnaire without rebuilding your evidence every time
The fastest questionnaire is the one your security evidence was already prepared to answer.
· 5 min read
ResearchResearch
The remediation truth gap
The farther closure moves from adversarial retesting, the more assumption remains in the remediation state.
· 4 min read
GuidesGuide
Building a security validation program your board can read
The board does not need the scanner console. It needs a defensible view of exposure, remediation and whether the testing program is working.
· 4 min read
BlogSecurity validation
A vulnerability is not an attack path
A finding matters differently when it exposes a credential, crosses a trust boundary or creates access to sensitive data.
· 3 min read
BlogContinuous validation
What continuous security testing should actually mean
Frequency tells you how often a tool runs. Continuity tells you whether security state survives between runs.
· 3 min read
ResearchResearch
The validation gap
Security teams often have abundant detection data and much less evidence about what an attacker can actually use.
· 4 min read
ResearchResearch
Four surfaces, fragmented security ownership
Organizations assign security ownership by technology. Attackers organize around reachable trust.
· 3 min read
GuidesGuide
What DORA actually requires of security testing
DORA changes the testing conversation from isolated evidence toward an operating resilience process that can be demonstrated.
· 4 min read
Keep going
Related
Stop assuming you are secure. Prove it.
Continuously test what an attacker can actually reach across your applications, SaaS identities, internal infrastructure and AI systems.