Core Capability
Web Application Penetration Testing
Manual, deep-dive testing of web applications and multi-tenant SaaS platforms. We exploit what we find, hand your developers the fix, and produce evidence your auditor accepts without translation.
- Every finding manually exploited — no scanner output forwarded as-is
- Mapped to the OWASP Top 10, SANS and NIST
- Tenant isolation testing informed by operating our own multi-tenant SaaS
What we test in a web application
An automated scan can tell you a library is out of date. It cannot tell you that a user on a trial plan can read another tenant's invoices by changing a single identifier. Web application testing at WIMD is manual work against the logic of your product, supported by tooling rather than led by it.
Authentication and session handling
- Credential handling, password reset and account recovery flows, including token predictability and reuse
- Multi-factor bypasses, including fallback channels and remember-this-device logic
- Session fixation, concurrent sessions, and token expiry and revocation on logout and password change
- Single sign-on and OAuth flows, redirect URI validation and state parameter handling
Authorisation and access control
- Horizontal and vertical privilege escalation across every role your product defines
- Insecure direct object references against every identifier we can enumerate
- Function-level authorisation on administrative, internal and undocumented endpoints
- Tenant isolation in multi-tenant deployments, covering data, files, background jobs and cached responses
Business logic
- Workflow sequence bypasses, such as skipping payment, approval or verification steps
- Quantity, pricing and discount manipulation in checkout and billing flows
- Race conditions on limited resources including coupons, inventory and credit limits
- Trust boundary failures where client-side validation is not enforced server-side
Injection and input handling
- SQL, NoSQL, command and template injection, including second-order variants
- Cross-site scripting across stored, reflected and DOM contexts
- Server-side request forgery, including access to cloud metadata endpoints
- XML external entities, insecure deserialisation and file upload handling
Why multi-tenant SaaS needs a different test
Most methodologies treat an application as one system with one user base. A multi-tenant platform is many logical products sharing a database, a cache, a job queue and an authentication layer. The interesting failures happen at those seams, and a generic checklist walks straight past them.
We look specifically at whether a tenant identifier is ever trusted from a request rather than derived from the session, whether background jobs and scheduled tasks inherit the correct tenant context, whether cached responses and exported files can cross a boundary, and whether an administrator inside one tenant can reach global functionality.
We know where to look because we built and still operate Isikko, a multi-tenant platform with custom authenticators, high-volume booking flows and live payment modules. These are failures we have had to design against as operators, not only find as testers.
How the engagement runs
1. Threat analysis and scoping
We map your architecture, roles, trust boundaries and the flows that carry genuine business risk, then agree scope and rules of engagement in writing before anything is touched.
2. Manual exploitation
Reconnaissance and application mapping, then hands-on exploitation against the prioritised paths. Automated tooling widens coverage; the findings that matter come from an engineer working through your logic. Every issue is proven with a working proof of concept before it enters the report.
3. Remediation handoff
We walk your engineers through each finding, supply the code-level fix rather than generic mitigation advice, and stay available while the patches are written.
What you receive
- A report containing only exploited, validated findings — no unverified scanner output
- Proof-of-concept steps, video recordings and the exact scripts used for each critical issue
- Code-level remediation guidance, including configuration and IAM changes where relevant
- Risk ratings framed in business terms your leadership can act on
- Evidence formatted for SOC 2, ISO 27001, PCI-DSS or HIPAA sign-off
- A live debrief with your engineering team
Common questions
Do you need access to our source code?
No. Most web application engagements run grey box: we work against the running application with credentials for each role. Source code makes certain classes of issue faster to confirm and we will use it where you can share it, but it is not a prerequisite.
Do you test staging or production?
Whichever carries the real risk, agreed with you in advance. A staging environment that mirrors production is usually safer for destructive test cases, but if staging differs materially from production the test loses its value. Where we work against production we agree a testing window, request rate limits and an escalation contact first.
How do you handle our WAF or rate limiting?
We test both with the protection in place and, where you permit it, with our source allow-listed. The first tells you what an ordinary attacker sees; the second tells you what is actually wrong underneath. Reporting only the protected view hides vulnerabilities that become exploitable the moment a rule changes.
How long does a web application engagement take?
It depends on the number of roles, the size of the authenticated surface and how much of the logic is bespoke, and the duration is fixed in the written scope before work starts. What drives it more than page count is role pairs: an application with eight roles takes considerably longer to test properly than one with three, because the combinations are what get tested.
Will testing take our application down?
Not in the way we work. Findings are confirmed with read-only and inference-based techniques wherever possible, destructive payloads are not run against production data, and anything that genuinely requires a write is agreed in advance and preferably run in a non-production environment. Rules of engagement, including a contact for stopping work, are written down before testing begins.
Do you retest after we fix the findings?
Retesting is part of how an engagement closes, because a finding is not resolved until the fix is verified — and auditors ask for that evidence specifically. What is included and how many rounds is stated in the written scope so there is no ambiguity later.
What do you need from us before you start?
Application URLs and environment details, one account per role including the ones you consider uninteresting, two accounts in the same role so peer access can be tested, and for multi-tenant systems accounts in two separate tenants. Anything you already know is weak is useful too — it tells us where to go deeper rather than where to stop.
Let's scope your infrastructure.
Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.