Find out what an attacker could break in your app

AI agents attack your web app with the tools real attackers use. Give them a test account and they test what a logged-in user can reach. Every finding comes with the requests and responses behind it, and a fix. The run starts minutes after you pay.

From €50 + VAT per run. No subscription, no sales call.

Auth
Recon

18m remaining

Live operations
Orchestrator

Initializing pentest session...

Controlling
The real run page, replaying highlights from one of our runs on ginandjuice.shop, a shop PortSwigger built to be hacked. Sped up to under a minute. Click any agent to read its log.

One 30-minute run on the same demo shop

Price
€50
Focused run, 30 minutes
Findings
9
findings
Time to first finding
About 2 min
to the first finding

Run it on your app. From €50 + VAT.

Why now

A pentest shouldn't cost €10K and take weeks

A traditional pentest costs €10-25K, takes weeks to book and ends in a PDF. You ship every day, so that PDF is out of date by the next release. With AttackerView you can pentest every release.

Compared onTraditional pentestAttackerView
Price€10-25K€50 to €400 + VAT per run
Getting startedWeeks to scheduleMinutes: add your app, pick a run, pay
ResultsA PDF at the endFindings appear while the agents work
After your next releaseBook and pay againRun it again from €50. Known bugs update in place, and a bug that comes back is flagged.

Teams at these companies use AttackerView

How it works

From sign-in to a running pentest in minutes

No scoping calls, no statement of work. You set it up yourself and watch it run.

  1. 1

    Add your app

    Sign in and add your app. Add a test account and the agents sign in with it and test what that account can reach.

  2. 2

    Pick a run and pay

    Focused runs up to 30 minutes for €50, Standard up to 90 minutes for €150, Deep up to 4 hours for €400, plus VAT. New to this? Start with Focused and watch what it finds.

  3. 3

    Watch it run

    Up to five agents map your app and attack it with curl, sqlmap, ffuf and a real browser. Findings show up while the run is going, and you can read every agent's log.

Teamwork

The agents pass each other leads

When one agent spots something worth a closer look in another part of your app, the next free agent picks it up right away.

1

An agent writes down what it notices

Each agent works on one part of your app. As it goes, it notes anything worth knowing: how the app is built, what looks weak, and where to look next.

POST|/catalog/product/stock
note_observation
  • Architecture Stock check posts an XML document
  • Weakness Parser resolves external entities
  • Lead Search results echo searchTerm GET /catalog high

Categories: Lead, Weakness, Architecture, Defense, Credential

2

A tip becomes the next job right away

A note that points at another part of your app goes straight into the shared queue, if it's in scope. The next free agent picks it up. Nobody waits for a batch to finish.

Queue by priority
  • high GET|/catalog claimed
  • medium GET|/my-account/orders
  • low GET|/blog

One entry per operation. Leads naming /catalog?category= and /catalog?searchTerm= count once.

Active (5/5 slots)
  • POST|/login
  • GET|/blog/post
  • POST|/catalog/product/stock
  • GET|/catalog/product
  • GET|/catalog new agent
How agents share what they learn, shown on ginandjuice.shop. Step 1: a tester working on POST /catalog/product/stock records an Architecture note, a Weakness note and a Lead for GET /catalog. Step 2: the lead joins the shared queue, which holds one entry per operation in priority order, and a free slot out of five takes it from the head of the queue as a new agent.

What you get

Every finding comes with the requests behind it

Before a finding reaches you, it's checked against the requests and responses the agent actually recorded, and claims that don't hold up are dropped. Each finding gives you the exact requests, a CVSS severity, the impact and the fix. This SQL injection is from a test on the demo shop: the agent switched the product listing off and on with two true/false pairs, and you can send the same requests yourself.

SQL injection in the catalog category filter

Verified on this target

The baseline and true/false responses were checked for the marker.

Assessment details

The recorded test demonstrates the finding on this target.

Severity (CVSS)

8.7 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Assessed for this target

Anyone can send the request without signing in, and the injected condition decides what the database returns.

Explanation

The category parameter of GET /catalog is placed into a SQL query without parameterisation. Appending a condition to the category changes which rows the database returns.

Prerequisites

Confirmed on this target: the catalog is public, so no account is needed.

PoC

  1. Request the catalog for a real category and note that Hibiscus Gin is listed.
  2. Append a true condition, ' AND 7=7-- , and the same product is listed.
  3. Append a false condition, ' AND 7=8-- , and the listing is empty, with the same 200 status.
  4. Repeat with a second integer (13=13 and 13=14) to rule out chance.

Evidence

Five requests to the same operation, differing only in the category value. See the evidence of record below.

Impact

Confidentiality

An attacker can ask the database yes/no questions about any data the query can reach.

Integrity

Not tested: this run was read-only.

Remediation

Use a parameterised query for the category filter, and reject category values that are not in the known list.

Evidence of record

  • baselineId · r1 · req-baseline
    Request
    GET https://ginandjuice.shop/catalog?category=Gin
    Response
    HTTP 200 OK
    Content-Type: text/html; charset=utf-8
    
    <h3>Hibiscus Gin</h3> <p>Floral, bright, a little tart.</p> <span class="price">$19.30</span> …
  • pairs[0].trueId · r2 · req-true-1
    Request
    GET https://ginandjuice.shop/catalog?category=Gin'%20AND%207%3D7--%20
    Response
    HTTP 200 OK
    Content-Type: text/html; charset=utf-8
    
    <h3>Hibiscus Gin</h3> <p>Floral, bright, a little tart.</p> <span class="price">$19.30</span> …
  • pairs[0].falseId · r3 · req-false-1
    Request
    GET https://ginandjuice.shop/catalog?category=Gin'%20AND%207%3D8--%20
    Response
    HTTP 200 OK
    Content-Type: text/html; charset=utf-8
    
    <section class="products"></section> <p>No products in this category.</p>
  • pairs[1].trueId · r4 · req-true-2
    Request
    GET https://ginandjuice.shop/catalog?category=Gin'%20AND%2013%3D13--%20
    Response
    HTTP 200 OK
    Content-Type: text/html; charset=utf-8
    
    <h3>Hibiscus Gin</h3> <p>Floral, bright, a little tart.</p> <span class="price">$19.30</span> …
  • pairs[1].falseId · r5 · req-false-2
    Request
    GET https://ginandjuice.shop/catalog?category=Gin'%20AND%2013%3D14--%20
    Response
    HTTP 200 OK
    Content-Type: text/html; charset=utf-8
    
    <section class="products"></section> <p>No products in this category.</p>

Typed proof

Kind
sqli-boolean
Parameter
category
Marker
Hibiscus Gin
Baseline
r1
Pair 1
true r2 · false r3
Pair 2
true r4 · false r5

Observed effect

kind
typed-proof
version
1
signature
sqli-boolean
details
The baseline and true/false responses were checked for the marker.
outcome
{"parameter":"query:category","marker":"Hibiscus Gin","baseline":{"requestId":"req-baseline","markerPresent":true},"pairs":[{"trueRequestId":"req-true-1","falseRequestId":"req-false-1","trueMarkerPresent":true,"falseMarkerPresent":false},{"trueRequestId":"req-true-2","falseRequestId":"req-false-2","trueMarkerPresent":true,"falseMarkerPresent":false}]}

Derived severity metrics

  • PR=N: The attack requests carried no credential context.

Cookies, auth headers and tokens are masked in what we store. See a sample report.

Safe by default

You decide what the agents can touch

By default the agents send no POST, PUT, PATCH or DELETE requests, apart from signing in your test account. Turn on data changes only if you want them tested. Logout pages and any paths you mark off-limits are never touched, and the agents stay on your app and its subdomains.

Agents can reach your app's host and its subdomains: ginandjuice.shop *.ginandjuice.shop
Example requests and what the guard does with each, in read only mode and with data changes allowed
RequestRead only (default)Data changes allowed
GET /catalog?category=Gin Allowed Allowed
GET /order/details Allowed Allowed
POST /catalog/cart Refused Allowed
POST /catalog/product/stock Refused Allowed
GET /logout

would end the session

Refused Refused
GET /billing/invoices

below off-limits /billing

Refused Refused
GET https://other-site.example/

not your host

Refused Refused

Can the agents change data?

  • No: read only (default) (selected)
  • Yes: they may create, change and delete data

Read only blocks POST, PUT, PATCH, DELETE and WebSocket requests. Signing in with your test account still works.

Off-limits paths

  • /logout
  • /signout
  • /billing

These paths and everything under them are never touched, whatever the method. /logout and /signout are always on the list. You add the rest.

Every request the agents send is checked before it reaches your app. Reads on your app and its subdomains are allowed. POST, PUT, PATCH, DELETE and WebSocket requests are refused unless you allow data changes. /logout, /signout and your off-limits paths are always refused. Every request is checked against your settings before it reaches your app.

Pricing

From €50 per run

You pick how long the agents work. A bigger app doesn't cost more.

RunAgents work forPrice
FocusedUp to 30 minutes€50 + VAT
StandardUp to 90 minutes€150 + VAT
DeepUp to 4 hours€400 + VAT
Traditional pentestWeeks to book€10,000 to €25,000

No subscription. Pay for the run and that's it.

If the agents never get to test your app, or something breaks on our side, you get a full refund, VAT included.

Starts in minutes.

Questions

Before you start

How is this different from a vulnerability scanner?

A scanner sends a fixed list of checks. The agents explore your app the way a user does, signed in if you give them a test account, and follow up on what they find with sqlmap, ffuf, curl and a real browser. Every finding comes with the requests and responses behind it.

What kinds of bugs does it find?

SQL injection, XSS, XXE, SSRF, path traversal, command injection, template injection, CSRF, and access-control bugs such as data anyone can read without signing in.

Is it safe to run on production?

By default the run is read-only: no POST, PUT, PATCH or DELETE requests apart from signing in with your test account. All agents share one budget of 600 requests a minute, and they slow down as soon as your server answers 429 or 503.

Can it test pages behind a login?

Yes. Give it a test account and the agents sign in with it, so they test what that account can reach.

See what the agents find in your app

From €50 + VAT. Starts in minutes. Full refund if the agents never get to test your app.

No subscription, no sales call.