IronSights

Manual application testing

Web Application Penetration Testing

Testers who use your application the way an attacker would, then show you exactly what they reached and how.

A scanner can tell you a library is out of date. It cannot tell you that changing one number in a URL returns somebody else's invoice.

48-hour critical alert
100% manual testing
30-day free retest

Our methodology

Testing that understands what the app does

Most serious application flaws are not missing patches. They are decisions: who is allowed to do what, which value the server trusts, what happens when a step in a workflow is skipped. Finding those needs a person who has learned the application.

We follow the OWASP Testing Guide, then go past it into your business logic, where the expensive problems usually live.

Mapping & enumeration

We walk the application as a real user first: every route, form, parameter, and hidden endpoint. Scanners miss what only appears after you log in and use the thing properly.

Authentication & sessions

Login, password reset, multi-factor, SSO, and how long a session really lives. We test whether a token still works after logout, and whether one user's token works as another.

Access control & logic

The flaws scanners cannot find. Can a standard user reach an admin route by changing an ID? Can an order be discounted twice? These need someone who understands what the app is for.

Injection & exploitation

OWASP Top 10 coverage where it applies: SQL injection, cross-site scripting, deserialisation, server-side request forgery. Where it is safe and in scope, we prove the impact rather than assert it.

Coverage

What we test.

Every role, every input, and the API behind it. We ask for a test account per role, because half the interesting findings only show up when you compare them.

Authentication & SSO flows

Role-based access control

REST & GraphQL APIs

Session & token handling

File upload & processing

Payment & checkout flows

Input validation & injection

Business logic abuse

The report

Written so a developer can reproduce each finding without calling us. Screenshots, the exact request and response, and the payload we used.

  • Executive summary for board and leadership
  • Findings rated by likelihood and impact
  • Reproduction steps with request and response pairs
  • OWASP Top 10 mapping for each finding
  • Access control matrix showing what each role reached
  • Remediation guidance written for developers

The retest

Application fixes go wrong more often than infrastructure fixes, because a patch in one place can be bypassed from another. We check the fix rather than trusting it.

  • Free retest of all remediated findings within 30 days
  • Clear pass or fail against each original finding
  • Written confirmation you can send to clients or insurers
  • Updated risk register reflecting remediation status

What you gain

What changes after the test

Four concrete outcomes from every web application test, documented and retestable.

Exploitable flaws closed

Findings your developers can reproduce from the report, fix, and have verified.

Answers for your clients

Evidence of independent testing, which is what enterprise security questionnaires ask for.

Fewer repeat defects

Each finding explains the underlying cause, so the same class of bug stops coming back.

Priority-ordered work

Ratings by likelihood and impact, so your team fixes the dangerous things first.

Common questions

Web app test questions answered.

Unsure what to put in scope, or whether to test staging or production? Talk to us first. Scoping conversations are free and we will tell you if you do not need a test yet.

Talk to a specialist →
  1. What is web application penetration testing?

    It is manual security testing of a specific application by a person, rather than a scan of your network. Our testers use the application the way an attacker would: creating accounts, changing values, chaining small weaknesses together, and trying to reach data or functions that should be out of reach. The result is a report showing what someone could actually do, with the steps to reproduce it.

  2. How is this different from an external penetration test?

    An external test looks at your internet-facing infrastructure: firewalls, VPNs, mail servers, and exposed services. A web application test goes deep into one application, usually from behind a login. If you build or run software that holds customer data, you want the application test. Most businesses eventually want both, and we can scope them together.

  3. What does a web application test cost?

    Most web application tests fall between $4,000 and $12,000. The number moves with how many user roles exist, how many features and inputs are in scope, and whether we test the API separately. We agree a fixed price at scoping, before any work starts.

  4. Do you need access to our source code?

    Not usually. Most tests are black box or grey box, meaning we work from the outside with a set of test accounts covering each role. If you want us to review the code as well, we can, and it finds a different class of problem. We will tell you at scoping which one suits your situation.

  5. Will testing break our application or affect real users?

    We test against a staging environment wherever one exists. When testing has to happen in production, we agree the rules of engagement first: what is off limits, which hours are safe, and who to call if something looks wrong. Destructive testing never happens without written approval.

  6. What do we get at the end?

    A written report with an executive summary, every finding rated by likelihood and impact, reproduction steps a developer can follow, and remediation guidance. We walk your team through it on a call. Anything you fix is retested free within 30 days.

Find out what your app gives away.

Clear scope, a fixed price agreed before we start, and findings your developers can act on the same week.