RedForge / Web & API

Real attacks against your web application and API.

Run the way somebody trying to get in would run them — including the endpoints a crawler never reaches, and the ones behind your login. Every finding arrives with the request that proves it.

What is covered

Seven assessments, one engagement.

Scoped together because attackers do not respect the boundary between them: an exposed staging host leads to an undocumented API version, which leads to another tenant’s records.

Broken access control — IDOR and BOLA

The single most common way one customer ends up reading another customer’s data. This is the class RedForge was built around.

How it works

We register two accounts of our own, then walk every identifier your product uses — order numbers, invoice links, profile IDs, file downloads, API object keys — and try to reach account A’s data while logged in as account B. Every hit is re-tested from a clean session.

How it helps

It answers the question a SaaS buyer actually asks, with evidence rather than inference. No real customer’s data is ever touched — both accounts are ours.

Web application penetration testing

Real attacks against your web application, run the way somebody trying to get in would run them.

How it works

We test login and password reset, forms, admin panels, file uploads, search and checkout for SQL injection, cross-site scripting, template injection, authentication bypass and session handling flaws. Anything flagged critical is proven by exploiting it in a controlled way first.

How it helps

Your developers get a reproducible request per finding rather than a scanner category, so the fix can be written and verified the same afternoon.

API security assessment

The REST, GraphQL and gRPC endpoints behind your app and your integrations — where the data actually lives.

How it works

We discover your endpoints, including undocumented and older versions still left running, then test authentication, per-object permissions, rate limiting, token handling and input validation on each one.

How it helps

Your website may be locked down while the API behind it is not. This tells you which is which, and which version of the API is the one still answering.

Business logic and race conditions

Bugs where nothing is technically broken — the application does exactly what it was told, and that is the problem.

How it works

We test the rules your business runs on: can a one-per-customer coupon be redeemed twice, can a withdrawal be requested twice in the same instant, can a price or a user role be set by the browser, can a checkout step be skipped. Timing attacks are sent as a single packet so the requests land together.

How it helps

These are the findings no scanner reports and no signature catches, because nothing is malformed. They are also the ones that cost money directly.

External attack surface assessment

Everything of yours that is reachable from the internet — including the servers nobody remembers running.

How it works

We map your full external footprint: subdomains, DNS records, certificate transparency logs, open ports and exposed services, forgotten staging environments and admin panels. Routine hygiene too — TLS configuration, security headers, and the SPF, DKIM and DMARC records that stop someone emailing your customers as you.

How it helps

Most breaches start at an asset nobody knew was still up. You cannot defend a host you have forgotten you own.

Subdomain takeover assessment

Abandoned subdomains still pointing at services you cancelled, which somebody else can now claim.

How it works

We find every subdomain you have and identify DNS records still aimed at deleted cloud services, GitHub Pages, Heroku or AWS resources. Each candidate is probed to confirm the service really is unclaimed — a live page on a claimed service is not a takeover.

How it helps

You reclaim or delete the record before somebody else serves their content on your domain, with your certificate and your reputation.

SaaS cross-tenant isolation

The security-questionnaire item you cannot answer honestly without testing it: can account A read account B’s data?

How it works

Someone on your side logs in once per tenant in a real browser and exports the session. We crawl as tenant A and replay as tenant B, testing object IDs and role boundaries across the surface those captures reveal.

How it helps

It answers the questionnaire item verbatim, with an artifact behind the answer rather than an assurance.

Past the login

The severe findings are behind authentication.

Most scanners never get there, so they report the marketing site and call it an assessment. We get in without breaking anything, because breaking a control is not in any engagement letter.

A human logs in once, in a real browser

You export that session and hand it to us. No credential stuffing, no CAPTCHA solving, no OTP interception — a person authenticates normally, exactly as your policy already allows.

The capture carries the request shapes

Actual query strings, body field names, real object IDs. A crawler infers none of those and a JavaScript bundle states none of them — which is precisely why a login POST body is where scanners miss things.

Ready to scope a web or API assessment?

Send us your targets and we will come back with an approach, a timeline and a price. No scanning of any kind until an authorization is signed.

Send us your scope