WEB APPLICATION PENETRATION TESTING

You get working exploits against your own web application, each one reproduced before anyone wrote it down.

Why they're looking

We were not happy with the sort of data that we got from one of our pen testing companies… It's just juvenile. If I wanted to do Burp Suite, I can do it myself. I'm not looking for that.

DevSecOps manager, networking-hardware manufacturer

Every candidate is reproduced before it counts.

A Cracken web application assessment in progress: the plan, a confirmed critical SQL injection with its proof-of-concept, and the list of vectors tested and found not vulnerable.

One run against a deliberately vulnerable test app, 32m 19s. Two candidates reached the gate. One came back a confirmed critical, with the payload that proved it. One came back not vulnerable, and the report says so.

Explore the
platform.

  • Reproducible findings

    Each finding carries the exact request, the captured signal, and steps your team can re-run.

  • Full surface map

    Recon writes every host, endpoint, parameter, form, API route and auth boundary into the Cybergraph — the live map of everything the run has found.

  • Auth boundary priority

    Login, registration, password-reset, session and role changes are worked first, before the rest of the map.

  • Ruled-out findings

    Anything that could not be reproduced is recorded with the reason it did not hold.

Scope

A run covers injection (SQLi, SSTI), XSS, authentication and session handling, access control and IDOR, SSRF, file upload and business logic. No source code, no internal network, no people. This is autonomous penetration testing: Cracken works the running application from the outside, against a target you authorised and under a policy you set.

  • It does not read your source code

    This is black-box work against a running application.

  • It does not fix anything

    Cracken validates exposure and stops — no patches, no config changes, no pull requests.

  • It stops at the application

    It does not test the network under it, the identity provider beside it, or the cloud account it runs in.

  • It does not measure your detection

    A proven exploit says the application was reachable, not that the SOC missed it.

Who this is for

Start testing

  • AppSec Lead

    Your scanner reports four hundred findings against one application. You need to know which three of them an attacker reaches through the login page.

  • Pentester

    You lose the first two days of every web engagement to mapping and session handling, before you start looking for anything interesting.

  • CISO

    You sign off on release dates. You want something behind that signature stronger than a clean scan report.

Questions

Do I need to hand over source code or credentials?

The web application penetration testing playbook needs no source code — it is black-box against the running application. Credentials are optional but change what is reachable: give it two test identities inside the same tenant and it can run the idor and access-control vectors that an unauthenticated run cannot get to.

We pentest once a year and ship every week. What covers the gap?

A run is on demand, not on a calendar: one web application penetration test took 32 minutes and 19 seconds end to end. The same playbook that produced last quarter's findings runs again against the deploy you shipped this morning, and each candidate still goes to a separate operation that has to reproduce it before it is written down. Whatever the annual test found, it found in code you have since replaced.

How is this different from running a vulnerability scanner?

A scanner reports that a signal was present. This playbook sends every candidate to a separate verification operation that must reproduce the exploit before it counts. Candidates that fail that gate are recorded as NOT PROVEN with the reason, never promoted on reasoning alone. NOT PROVEN is not the same as not vulnerable, and the report keeps them apart: a vector that was tested and held up is recorded as “Tested — NOT vulnerable”.

Can it break my application?

Yes, and you should plan for that. sqlmap at higher risk and level settings, credential brute forcing with hydra, and file-upload testing all write to the target. Run it against staging, or leave the default trust setting alone: anything that writes then waits for a person to approve it instead of firing.

Point Cracken at your app.

Bring the target, the access level, and the rules of engagement.

Start testing