Skip to content
HackIT
Talk to a tester

Web Application Penetration Testing

Manual testing of your web application and its APIs by a senior tester. Every finding comes with evidence and reproduction steps, and a retest once your fixes ship.

Talk to a testerSee what we test
>_ finding HK-12Report
HighCVSS 8.1CWE-639

Any signed-in user can change other customers’ orders

shop.example.com

>_ evidenceHTTP
PATCH /api/orders/10482 HTTP/1.1Host: shop.example.com{"status":"cancelled"}HTTP/1.1 200 OK{"id":10482,"owner":"cust_2291","status":"cancelled"}# sent from a different customer’s session
Impact
Order numbers are sequential and ownership is never checked, so any signed-in user can read or cancel another customer’s order by changing the number.
Fix
Check that the order belongs to the signed-in user on every request, and use unguessable identifiers as a second layer.
StatusClosed on retest
Every finding in your report is written up like this, with evidence attached, and retested once your fix ships.

Why Test Your Web Application

A scanner finds known patterns. The flaws that hurt sit in how your application behaves, and only a person trying to break it finds those.

  • Authorization Fails Quietly

    Nothing errors when one customer can open another customer’s data. Access-control flaws look like normal traffic, so only testing with real accounts shows them. OWASP’s Top 10:2025 ranks Broken Access Control first.

  • Small Flaws Chain Into Big Ones

    A low-rated finding can become account takeover once it meets a second one. We test the way an attacker uses the application, not one checklist item at a time.

  • A Report You Can Hand Over

    Audits and customer security reviews ask for evidence of independent testing. PCI DSS requires it; SOC 2 and ISO 27001 audits accept it as proof your controls work.

When to Test

  • Before a launch or major release

  • After significant changes, such as new login, payments or integrations

  • On a regular cycle, at least yearly

  • Before an audit or a customer’s security review

Not sure which applies?That’s what the scope call is for

What We Test

Compliance audits cover the chapters of the OWASP Application Security Verification Standard (ASVS) 5.0 that apply to your application: chapters for technology you do not use, such as OAuth or WebRTC, are left out. Attack simulations draw on the same chapters but follow impact, not the checklist.

Tested against

OWASP ASVS 5.0Web applications and services

17 chapters

  • Encoding and SanitizationV1
  • Validation and Business LogicV2
  • Web Frontend SecurityV3
  • API and Web ServiceV4
  • File HandlingV5
  • AuthenticationV6
  • Session ManagementV7
  • AuthorizationV8
  • Self-contained TokensV9
  • OAuth and OIDCV10
  • CryptographyV11
  • Secure CommunicationV12
  • ConfigurationV13
  • Data ProtectionV14
  • Secure Coding and ArchitectureV15
  • Security Logging and Error HandlingV16
  • WebRTCV17

Two Ways to Test. Your Call.

Both are manual, senior-only and include a retest. Pick the one that matches why you are testing.

Compliance Audit

Full ASVS coverage

A complete, documentation-grade penetration test mapped to OWASP ASVS 5.0, the standard built for testing web applications and services. PCI DSS requires penetration testing, and SOC 2 and ISO 27001 audits accept it as evidence that your controls work. This engagement gives you that evidence, ready to present to your auditor.

Tested against

  • OWASP ASVS 5.0Web applications and services

Supports audit evidence for

  • SOC 2
  • ISO 27001
  • PCI DSS

Best for

Audits and certifications (SOC 2, ISO 27001, PCI DSS), or a complete security baseline of an app.

Scope a compliance audit

Real-World Attack Simulation

Impact-first. No noise.

Skip the documentation theatre. We focus on what an actual attacker would exploit: high-impact vulnerabilities with real, demonstrable consequences. No findings padding, no minor informational items. If it can be weaponised, we find it and prove it.

Tested against

  • OWASP ASVS 5.0Web applications and services
  • Manual only
  • Impact-first
  • No noise

Best for

Teams that want to know what an attacker could actually do, rather than tick every control.

Scope an attack simulation

What You Receive

Both engagements end with the same deliverable: a PDF written for two audiences, plus a conversation.

Showing the Executive Summary page of a sample report.

How an Engagement Runs

The same five steps for both engagements, and you deal with the tester at every one.

  1. 01

    Inquiry

    You send a message, by the form or by email. It goes straight to the tester, not to a sales team.

  2. 02

    Scope Call

    A call with the tester to agree targets, timelines and rules of engagement.

  3. 03

    Test

    Manual, senior-only testing: full ASVS coverage, or real attack paths.

  4. 04

    Report and Debrief

    Evidence, reproduction steps, severity and fixes per finding. We walk you through every one.

  5. 05

    Retest

    Included, not upsold. Once fixes ship, we verify each finding is actually closed.

How Pricing Works

  • Scoped, Not Sold by the HourEvery engagement is priced after a scoping conversation, for exactly what you need tested. Nothing padded.
  • Retest IncludedVerifying your fixes is part of every engagement, never a paid add-on.
  • Retainer DiscountsRepeat clients get better rates. Security is ongoing, and we price accordingly.
  • No Overhead to FundNo sales team or account managers, so senior testing comes in at roughly 40% below typical market rates.

Ready to Test What Actually Matters?

Tell us what you want tested. No sales call: your message goes to the tester, who replies to scope the work with you.

Prefer email?
contact@hackit.ee
Engagement (optional)

How we handle this: privacy policy