Web Application Penetration Test

Access to the environment you want tested, through a VPN or an allowlist of our IP addresses if it isn't public, and two test accounts for each role, so that we can check whether one user reaches another user's data. Where the flows need it, we also ask for test data, such as products, orders, payment test cards or users that are already set up.

No. A WAF blocks known attack patterns, but it doesn't fix the flaw behind them: with a different payload, or a request the WAF doesn't inspect, the flaw can still be exploited. Logic flaws have no pattern to recognize at all: to a WAF, a request that exploits a missing access check or gets around a business rule looks like any other. During a test, though, the WAF could block our attempts or our IP addresses and hide flaws that an attacker with more time would still reach. That is why we ask you to allowlist our IP addresses on the WAF or CDN: we see the flaws that are actually in your application, and we still check how effective the WAF is.

In part. In a single-page application much of the logic runs in the browser, where anyone can read and change it: hiding a button or a page from a role doesn't stop that role from calling the API behind it. So besides the interface, we test what the server enforces on every call, and we look at what the JavaScript code reveals, such as hidden routes, endpoints or keys.

The site as it is built: the CMS, the plugins and themes you installed and any code written for you, together with how they are configured. A single outdated or poorly written plugin can be enough to compromise the whole site, so we test each component, not just the version of the core.