Most breaches of web applications do not start with an exotic exploit. They start with a request the application should have refused: an invoice of another customer, a price changed in transit, a password reset that trusts the wrong header. Scanners miss these flaws because they do not know what the application is for.
We test as authenticated users of every role, map what each role can reach and then try to cross every boundary between them. Automated tools cover the known classes. The time of the specialists goes into logic, access control and chains of small weaknesses that add up to a compromise.
01Scope
What we test
Authentication, sessions, password recovery and multi-factor authentication
Horizontal and vertical access control, tenant isolation
Business logic: payments, discounts, limits, workflows, race conditions
Injection: SQL, NoSQL, command, template, XML external entities
Grey box by default: we work with accounts and documentation, because that finds the most in the time available. Black box is appropriate when you want to measure what an outsider achieves with no information. White box adds the source code and is described under secure code review.
Do you test in production?
We prefer an environment that matches production. Where only production exists, we agree test windows, avoid destructive actions and work with our own test data.
Is a vulnerability scanner not enough?
A scanner finds known patterns in single requests. It does not know that one customer must not see the orders of another, or that a discount must not be applied twice. Those flaws are found by people who understand the application.