An automated penetration test of your web applications, run while logged in. It tests up to 10 web apps and the APIs behind them, tries to exploit what it finds, and shows you how each attack worked. Then you get 30 days to fix what it found and test again.
Each test is quoted per project, based on how many apps you need tested. Need a person doing the testing instead? We offer that too.
-
Tested behind the login
Using test accounts you give us, one per user role. -
10 apps for 30 days
That's a standard test. Bigger scopes are quoted too. -
Unlimited retests
Fix a finding and run the same attack again. -
Proof, not guesses
Each finding shows the attack that worked and how to fix it.
Web app test or network test?
They answer different questions. Our network penetration test goes wide. It covers up to 10 IP addresses from outside your network, with testing from inside as an option, and tells you where your overall risk is. The web app test goes deep. It logs in to the apps you name and asks how an attacker could abuse them. Here's the thing: a network test might spot that a login page has weak password rules. A web app test can show whether a normal customer can get from "view my profile" to "edit someone else's billing details".
| Network test | Web app test | |
|---|---|---|
| What it tests | Servers, open services and anything else on your IP addresses. | Your web apps, their APIs, logins and user roles. |
| Logged in? | No. It sees what an outsider sees, or an intruder on your network if you add internal testing. | Yes. It tests as each kind of user you give us an account for. |
| Best for | Knowing your overall risk, and PCI DSS 11.4 network testing. | Customer portals, checkouts, SaaS apps, and anything about to launch. |
| Weak spot | Misses flaws that only show up after you log in. | Covers only the apps you name, not your wider network. |
Many businesses need both. A good pattern is to start wide with the network test, pick the apps that matter most, and test those in depth.
What the test covers
A scanner might flag a form field as a possible SQL injection and stop there. This test tries the attack and shows what it gets: another user's account, say, or rows out of your database. It keeps the session going like a real user would, so it can follow multi-step flows like sign-up, checkout or a password reset.
| Access control | Can one user reach another user's data? Can a normal user open admin pages? Can someone change an ID in the URL and see an order that isn't theirs? |
|---|---|
| Common web attacks | SQL injection, cross-site scripting, cross-site request forgery, server-side request forgery, and file upload flaws. |
| Logins and sessions | Weak login rules, session tokens that can be stolen or reused, and password resets that can be abused. |
| APIs | The REST endpoints your app uses, tested with the same logins. |
| Setup mistakes | Debug pages, exposed files, missing security headers, and anything else that hands an attacker a head start. |
| Retesting | Unlimited for 30 days. Re-run the exact attack to prove each fix works. |
How it works
Request a quote
Tell us on the quote form how many web applications to test.
Get your quote
Scope, timing and cost, usually within one business day.
Set up test accounts
One login for each kind of user, and anything that's off limits.
The test runs
At a time you pick. Findings show up as it goes.
Fix and retest
Get the report, fix what it found, and test again until your 30 days are up.
What to have ready
The test goes faster when you have these sorted before it starts. The URLs of each app, and any APIs or pages to leave out. A test account for each user role, like customer, staff and admin, so the test can check what each one should and shouldn't reach. Whether we're testing your live site or a staging copy, and whether real customer data is in it. And any times to avoid, like a sale or a release day.
What you get
A report your developers can work from and your assessor can file. It opens with a short summary for management. Then each finding gets its own entry: what's affected, how serious it is, the steps and requests that reproduce it, and how to fix it. When you retest, the report shows which fixes held.
Automated, or a person doing the testing?
Our default test is automated, which is what makes it quick to schedule and easy to repeat after every release. But software can't know every rule your business runs on. It won't know that a discount code should only work once, or that a refund should never be bigger than the order. A person can test for that. So we also offer a test run by a dedicated tester, who works through your app by hand. If your app handles payments, approvals or account changes in ways that are unique to you, it's worth asking about. Say so when we come back with your quote.
Does PCI DSS require it?
If your SAQ asks for a penetration test, yes. PCI DSS Requirement 11.4.1 says the test must cover the application layer and look for at least the flaws listed in Requirement 6.2.4, like injection, broken access control and business logic abuse. So a merchant on SAQ D or SAQ A-EP with a web app in scope needs this kind of testing once a year and after big changes. Our SAQ guide shows which form is yours. Outside PCI DSS, the same report is often used for SOC 2 audits, customer security questionnaires and cyber insurance renewals.
Web app penetration testing pricing
Every test is quoted per project, because the work depends on scope. The quote depends on how many apps you have, how many user roles each one has, and whether APIs are in scope. If you have more than 10 apps, need longer than 30 days, or want a dedicated tester, we quote that too. Want your network tested as well? Put your IP addresses on the same quote form.
Common questions
Is it safe to run against my live site?
Yes, by default. The test proves a flaw is real without breaking anything, and checks that could change or delete data only run if you ask for them. You can leave out pages, pick the time, and pause the test at any point. It does submit forms and create records with the test accounts, so many customers point it at a staging copy instead.
Can you test an app before it launches?
Yes, as long as the test can reach it. Testing a staging copy before launch is one of the best times to do it, because fixes are cheaper before customers arrive.
Why do you need test accounts?
Most of the serious flaws in a web app sit behind the login. Without an account the test only sees your sign-in page. With one account per role, it can check whether a customer can reach staff pages, or one customer can see another's data. Use test accounts, not real ones, and turn them off when the test is done.
Do I need to install anything?
No. The test reaches your app over the internet, the same way your users do.
Is this the same as an ASV scan?
No. The ASV scan is a quarterly check of your public IP addresses for known weaknesses, under Requirement 11.3.2. It doesn't log in and doesn't try to break in. This test does both. Our comparison of scanning and penetration testing sets them side by side.