CyberFortify is a Bahrain-based penetration testing company delivering manual, exploit-driven web application pen testing aligned with OWASP Top 10 and OWASP ASVS. Engagements cover single-page apps, server-rendered platforms, multi-tenant SaaS and headless backends - with audit-ready reports your QSA, ISO assessor or SOC 2 auditor can use as direct evidence.
// 01 What is web application penetration testing?
A controlled, manual security assessment in which qualified offensive security engineers attempt to exploit vulnerabilities in a web application the same way a real attacker would - chaining weaknesses into proof-of-concept exploits and producing evidence-grade reporting your engineering organisation and external auditors can use.
Not the same as a vulnerability scan. A scanner emits a list of potential issues with no validation of business impact. A pen test demonstrates real exploitability against your specific business logic.
The discipline has evolved sharply over the last decade. Modern web applications are no longer monolithic server-rendered pages with form posts. Today's attack surface includes single-page apps backed by JSON APIs, headless commerce platforms, micro-frontends consumed through module federation, edge functions running on global runtimes, multi-tenant SaaS platforms with elaborate permission systems, and complex single sign-on flows that bridge dozens of identity providers. Each of these layers introduces vulnerability classes that automated scanners cannot model. CyberFortify's web application pen testing services are explicitly built for this modern stack.
The OWASP categories that consistently dominate breach data - broken access control, injection, authentication failures, server-side request forgery - are also the categories scanners are weakest at finding. Manual testing closes that gap.
CyberFortify offensive security teamThe OWASP Top 10 categories that consistently dominate breach data - broken access control, injection, identification & authentication failures and server-side request forgery - are also the categories scanners are weakest at finding. Manual testing closes that gap.
// 02 What's in scope
A typical CyberFortify web application penetration testing engagement covers the application's full authenticated surface area, scoped collaboratively during the pre-engagement conversation. We rarely test a single page in isolation; the most damaging real-world attacks chain weaknesses across components, identity boundaries, business workflows and shared services.
Application surface
Single-page applications
React, Vue, Angular, Svelte, Solid, Qwik and Next.js - including server components, edge runtimes and module-federation micro-frontends.
Server-rendered platforms
PHP (Laravel, Symfony), Java (Spring), .NET, Ruby (Rails), Python (Django, Flask, FastAPI) and Go.
Multi-tenant SaaS
Custom RBAC, role hierarchies, data-room isolation and tenant-scoped object stores. Cross-tenant boundary testing is a flagship CyberFortify focus.
Headless backends & BFFs
REST, GraphQL and gRPC layers - covered in depth on our API security testing service page.
Identity flows
OAuth2 / OIDC, SAML 2.0, custom SSO bridges, magic-link authentication, passkeys and WebAuthn registration.
Real-time channels
WebSockets, Server-Sent Events, WebRTC signalling and long-polling fallbacks - protocol-aware authentication and authorisation testing.
Privileged surfaces
Admin consoles, internal APIs, support tools, billing dashboards and tenant-management interfaces. Often the highest-impact, least-tested layer.
Edge & serverless
Vercel / Cloudflare / Netlify edge functions, Lambda@Edge, Durable Objects - trust-boundary review where developers underestimate input.
Vulnerability classes we test for
Findings on CyberFortify engagements are classified using OWASP categories, mapped to MITRE ATT&CK adversary techniques where applicable, and scored using CVSS v3.1 with environmental modifiers. The list below is a non-exhaustive sample of what we look for in every engagement.
| Class | Examples | Severity range |
|---|---|---|
| Broken access control | IDOR, vertical & horizontal privilege escalation, tenant boundary bypass, force-browsing | Medium - Critical |
| Injection | SQL, NoSQL, LDAP, command injection, ORM injection, server-side template injection | High - Critical |
| Authentication failures | Credential-stuffing tolerance, password reset abuse, session fixation, MFA bypass | Medium - High |
| SSRF | Cloud metadata exfiltration, internal service discovery, URL parser confusion | High - Critical |
| Cryptographic failures | Weak hashing, insecure JWT signing, predictable tokens, transport downgrade | Medium - High |
| Deserialization | Unsafe Java/PHP/Python/Ruby deserialization, gadget chains, custom format abuse | High - Critical |
| Business logic | Race conditions, payment flow abuse, coupon stacking, refund chaining, invariant violations | Medium - Critical |
| SSRF / template injection | SSTI in Jinja, Twig, Razor, Liquid; reflective / non-blind variants | High - Critical |
| Misconfiguration | Verbose errors, exposed admin panels, default credentials, debug endpoints | Low - High |
| Client-side | DOM XSS, prototype pollution, postMessage abuse, click-jacking, CSP bypass | Low - High |
// 03 Our web application pen testing methodology
Every CyberFortify web application pen test follows a documented seven-phase methodology grounded in the Penetration Testing Execution Standard (PTES) and aligned with NIST CSF and OSSTMM. The methodology is reproducible, audit-defensible, and produces deliverables your security team can use long after the engagement closes.
Pre-engagement & scoping
We collaboratively define targets, in-scope domains, user roles, test windows and rules of engagement. A signed authorisation letter and emergency contact tree are agreed before any traffic touches the application.
Reconnaissance & mapping
Passive and active enumeration of subdomains, JavaScript bundles, API contracts (Swagger / OpenAPI / GraphQL introspection where applicable), source-map exposure, exposed environment variables and forgotten staging environments. Many of our most impactful findings start here.
Threat modelling
We translate the application's components into a STRIDE-style threat model, mapping data flows, trust boundaries and high-value assets. The model becomes the prioritised test plan for the rest of the engagement.
Vulnerability identification
Manual testing for OWASP Top 10 and ASVS L1-L3 controls is augmented with carefully tuned automation (Burp Suite Pro, custom Caido workflows, ZAP for regression sweeps, semgrep for static review where source is provided).
Exploitation & chaining
Confirmed weaknesses are exploited under controlled conditions, chained into realistic attack paths, and documented with CVSS scoring, reproduction steps and screenshots. Critical findings are reported within 24 hours of validation.
Reporting & remediation playbook
You receive an executive summary, a detailed technical report, and a remediation playbook your engineers can ticket directly into Jira, Linear or Asana.
Free remediation retest
Once your team ships fixes, we revalidate every closed finding at no additional cost and issue an updated attestation report many of our customers share with enterprise buyers and auditors.
// 04 Black-box, gray-box and white-box engagement models
The phrase web application penetration testing covers three distinct engagement models, each modelling a different attacker. The right model is a function of your threat profile, regulatory driver and the maturity of your security programme. CyberFortify recommends a model during scoping; most production SaaS workloads benefit from gray-box, while pre-launch or pre-acquisition diligence typically calls for white-box.
Black-box pen test
External attacker simulationZero credentials, zero source, zero documentation. The tester operates exactly as an internet adversary would, starting from your public domain.
- Best for marketing-driven attestation and adversary simulation
- Highest realism, lowest depth-per-day
- Surfaces external recon hygiene weaknesses
- Common pairing: red team operations
Gray-box pen test
Compromised user simulationLow-privilege test credentials per role, no source code. Models the realistic post-phish or post-credential-stuffing attacker - the most common breach precursor in 2026.
- Default model for SaaS, fintech and digital health
- Optimal coverage-per-day for SOC 2 / ISO 27001
- Tenant-isolation and IDOR testing depth
- Recommended for the OWASP ASVS Level 2 verification
White-box pen test
Maximum-depth assuranceFull source-code access, architecture diagrams, threat models and privileged credentials. Combines manual pen testing with targeted code audit on high-value flows.
- Pre-launch hardening of payment, auth or PHI flows
- Pre-acquisition technical due diligence
- OWASP ASVS Level 3 verification depth
- Highest finding density per engagement day
// 05 When to commission a web application pen test
Most regulated organisations are required to perform a web application penetration test at least annually, but the highest-leverage moments to test are tied to product, infrastructure and compliance events. The triggers below are where CyberFortify customers typically commission engagements.
Annual audit cadence
SOC 2 Type II surveillance, ISO/IEC 27001 A.8.29, PCI DSS Requirement 11.4 and HIPAA 164.308(a)(8) all expect a current-year penetration test report. We deliver in your audit calendar window.
Major release or re-platform
Launch of a new product line, migration from monolith to microservices, switch to a new identity provider, or rollout of a new tenant model. Test the change while it's still cheap to fix.
Enterprise security questionnaire
A six- or seven-figure deal blocked behind a vendor security review. We deliver a redacted executive summary your buyer's CISO will accept - same week, in many cases.
Pre-acquisition technical diligence
Buy-side or sell-side diligence on a SaaS target. White-box engagement to surface security debt that materially affects valuation or post-close integration cost.
Post-incident assurance
After a security incident or near-miss, a fresh penetration test validates that the root cause is fully remediated and surfaces adjacent weaknesses the incident did not expose.
Series B+ security maturation
Venture-backed SaaS companies typically formalise their security programme between Series B and C. A first independent web application pen test is the canonical kickoff for that maturation.
// 06 Common findings from recent engagements
The findings below are anonymised, severity-coded snapshots from recent CyberFortify web application penetration testing engagements. They illustrate the gap between automated scanner output and what a manual tester actually finds in production-grade applications.
Cross-tenant document exfiltration via predictable identifiers
A sequential UUID v1 generator allowed an authenticated tenant to enumerate document IDs across other tenants. Manual analysis of timestamp entropy in the UUID exposed roughly 4,000 cross-tenant documents in 11 minutes of testing.
Cloud metadata exfiltration via webhook URL parser
A webhook configuration UI accepted any URL host, including AWS instance metadata service. The tester pivoted to extract IAM credentials with permissions to list S3 buckets across the tenant data plane.
JWT signature stripping via alg-confusion
The application accepted both RS256 and HS256-signed tokens, with the same key store. A tester re-signed an admin claim using the public key as the HS256 secret to escalate to tenant-owner role.
Privilege escalation via mass assignment on profile update
The profile update handler bound JSON payloads directly to the user model without an allow-list. A non-privileged user could escalate to admin and reassign billing ownership in a single request.
Coupon stacking via parallel checkout race
The coupon-application endpoint did not lock the cart row. Sending 32 concurrent requests applied a 25% off coupon four times, resulting in a 100% discount before checkout. A pure scanner cannot model this.
SameSite-Lax bypass via top-level GET state-change
Critical state-changing actions were exposed through GET requests, allowing a top-level navigation from a malicious site to bypass SameSite=Lax cookies and silently reassign the account email.
// 07 Web app pen test vs vulnerability scanning, DAST, SAST and bug bounty
Customers regularly ask how a manual web application penetration test differs from automated alternatives. The matrix below compares the five most common options. Mature security programmes use several of these in combination - automation for breadth, manual pen testing for depth, and bug bounty for ongoing coverage between annual engagements.
| Capability | Manual pen test | Vulnerability scan | DAST | SAST | Bug bounty |
|---|---|---|---|---|---|
| Business-logic flaws | Yes | No | No | No | Variable |
| Chained exploit paths | Yes | No | No | No | Variable |
| Authenticated coverage | Full RBAC | Limited | Limited | N/A | Yes |
| False-positive rate | < 1% | High | High | Very high | Low |
| Audit-evidence quality | Direct | Insufficient | Supplemental | Supplemental | Supplemental |
| SOC 2 / ISO 27001 / PCI 11.4 | Satisfies | No | No | No | No |
| Cadence | Annual / on change | Continuous | Per release | Per commit | Continuous |
| Cost predictability | Fixed | Fixed | Fixed | Fixed | Variable |
| Time to first finding | Hours | Minutes | Minutes | Minutes | Days-months |
The verdict customers reach: keep automation running continuously for breadth, run a CyberFortify manual web application pen test annually (and on major change) for depth and audit evidence, and add a private bug bounty programme once your remediation pipeline is mature enough to absorb incoming submissions without burning out engineering.
// 08 Pricing model and cost factors
CyberFortify web application pen testing services are fixed-price, scoped collaboratively during a 30-minute call. We do not bill hourly, and the price you receive is the price you pay including reporting and the free remediation retest. The factors below are the dominant cost drivers.
Application size & surface
Number of distinct screens, API endpoints, microservices, third-party integrations and exposed admin surfaces.
High impactUser roles & tenancy
Number of authenticated user roles, multi-tenancy depth, custom RBAC complexity and impersonation flows.
High impactBusiness-logic depth
Complexity of payment, billing, content moderation, file workflows and other domain-specific invariants.
High impactEngagement model
Black-box is fastest-to-quote; gray-box is the standard SaaS engagement; white-box adds source-code review days.
Medium impactIdentity stack
Custom SSO bridges, multi-IdP federation, B2B tenant invites and passkey rollouts add testing surface.
Medium impactCompliance evidence depth
SOC 2 / ISO 27001 / PCI / HIPAA mapping is included; bespoke evidence packs (SIG, CAIQ, NIST 800-53) add scope.
Low impact// 09 Engagement timeline week by week
A typical CyberFortify web application penetration testing engagement spans four weeks end to end. Active testing sits in the middle; the bookends are scoping, reporting and the free remediation retest. Critical findings are reported within 24 hours of validation regardless of phase.
Scoping & authorisation
- 30-minute scoping call
- Fixed-price quote within 48h
- Rules-of-engagement letter
- Test accounts & allow-listing
- Threat model captured
Recon & vulnerability discovery
- Surface enumeration
- Authenticated workflow walk
- OWASP Top 10 manual sweep
- ASVS L2 verification pass
- Daily standup with your team
Exploitation & chaining
- Confirmed exploit PoCs
- Business-logic abuse cases
- Tenant-boundary chaining
- Critical SLA: 24h disclosure
- Draft findings sent rolling
Reports & remediation
- Executive summary delivered
- Technical findings report
- Compliance evidence pack
- Live remediation walkthrough
- Free retest scheduled
// 10 Tooling and offensive tradecraft
Tooling alone does not make a penetration test - tester judgement does. That said, our engineers use a combination of industry-standard offensive tooling, custom internal tooling developed across hundreds of engagements, and selectively tuned automation to ensure broad coverage. Common tooling on CyberFortify web application pen testing services includes:
// 11 What you receive at the end of the engagement
Every CyberFortify web application penetration testing engagement concludes with five deliverables designed to satisfy three distinct audiences: your security team, your engineering organisation, and your auditors or enterprise buyers.
Executive summary
A non-technical 2-4 page narrative for leadership and the board. Risk posture, headline findings, business impact, recommended next steps. Designed to be read in five minutes.
Technical findings report
Full writeup of every finding with CVSS v3.1 (base + environmental + temporal), CWE classification, OWASP Top 10 / ASVS mapping, reproduction steps, evidence and remediation guidance written for the developers who will fix it.
Remediation playbook
A structured, ticket-ready breakdown of every finding into atomic engineering tasks. Severity-ordered, with acceptance criteria. Designed to drop straight into Jira or Linear.
Compliance evidence pack
Cross-mapping of every finding to the controls your auditors will request - SOC 2 (CC6.1, CC7.1, CC8.1), ISO/IEC 27001:2022 (A.8.8, A.8.29), PCI DSS v4.0 (Req. 11.4), HIPAA (164.308(a)(8)) and GDPR Art. 32(1)(d). Our compliance consulting practice can operationalise the rest.
Free remediation retest & attestation
After your team ships fixes, we revalidate every closed finding at no additional cost and issue an updated attestation. Many customers share the attestation with their largest enterprise buyers as part of the security questionnaire response.
// 12 Standards and framework mapping
Web application pen testing reports from CyberFortify map to recognised industry standards on every finding. This eliminates weeks of mapping rework during your audit cycle and guarantees your assessor receives the references they expect.
| Standard | Mapped reference | Used for |
|---|---|---|
| OWASP Top 10 | A01 - A10 (current edition) | Application risk classification |
| OWASP ASVS | L1 / L2 / L3 verification levels | Coverage depth statement |
| PTES | Phases 1-7 | Methodology grounding |
| MITRE ATT&CK | Initial Access, Credential Access, Lateral Movement | Adversary technique mapping |
| SOC 2 | CC6.1, CC7.1, CC8.1 | Trust Services Criteria evidence |
| ISO/IEC 27001:2022 | A.8.8, A.8.29, A.5.7 | ISMS surveillance audits |
| PCI DSS v4.0 | Requirements 11.4.1 - 11.4.7 | Cardholder data environments |
| HIPAA Security Rule | 164.308(a)(8) evaluation | ePHI environments |
// 13 Industries we serve
Every CyberFortify engagement is tailored to the threat model, regulators and buyer expectations of the vertical we operate in. The industries below represent the bulk of our web application pen testing delivery to date.
SaaS startups
SOC 2Multi-tenant platforms preparing for their first SOC 2 Type II audit, where tenant isolation and access control are the headline risks.
Fintech
PCI DSSPayment platforms and lending products validating PCI DSS Requirement 11.4 obligations on cardholder data environments.
Digital health
HIPAATelehealth, EHR integrations and clinical workflows handling ePHI under the HIPAA Security Rule and 164.308(a)(8).
E-commerce
PCI · ATOMarketplaces and DTC platforms defending against account takeover, payment skimming and discount-flow abuse at scale.
Global enterprise
ISO 27001Organisations running ISO/IEC 27001-certified Information Security Management Systems with annual A.8.29 surveillance audits.
AI / data platforms
SSRF · PIILLM-driven products and data pipelines where prompt-injection-adjacent risks, SSRF and tenant data leakage dominate the threat model.
// 14 Why CyberFortify for web app pen testing
Automated scanner output
A list of CVEs without exploitation context. False positives common. No business-logic flaws. No chained exploit paths. Reports rejected as audit evidence.
CyberFortify manual web app pen testing
Every finding hand-validated. Real exploit chains with proof-of-concept evidence. Business-logic abuse uncovered. Reports drop straight into your auditor's working paper. Free retest included.
// 15 Frequently asked questions
How long does a web application penetration test take?
A typical CyberFortify web application pen testing engagement runs five to fifteen business days of active testing. Smaller marketing sites or single-feature apps sit at the lower end; large multi-tenant SaaS platforms with multiple authenticated user roles and complex business logic sit at the upper end. Total elapsed time including scoping, reporting and remediation retest typically spans four to six weeks.
Do you do white-box, gray-box or black-box testing?
All three. Black-box (no credentials, no source) simulates an external attacker and is appropriate for marketing-driven assessments. Gray-box (low-privilege credentials only) is the most common SaaS engagement. White-box (privileged credentials plus source-code access) produces the deepest coverage and is recommended for high-stakes applications such as payment platforms and clinical systems. We will recommend the right model during scoping based on your threat profile.
How is this different from a vulnerability scan?
A vulnerability scan is automation; a penetration test is human-led offensive engineering. Scanners enumerate known CVEs in software versions; pen testers chain weaknesses into exploit paths, abuse business logic that scanners cannot model, and validate impact. Most importantly, audit evidence requirements (PCI DSS 11.4, ISO 27001 A.8.29, SOC 2 CC7.1) explicitly require penetration testing, not scanning.
What does it cost?
Engagements are fixed-price, scoped collaboratively. Pricing is driven by application size, number of authenticated user roles, depth of business logic and the testing model (black / gray / white box). Most CyberFortify web application pen testing engagements fall between a small focused assessment and a multi-week deep-coverage review. Schedule a 30-minute scoping call for a fixed-price quote, typically returned within 48 hours.
Can the test be done on production?
Yes, with care. CyberFortify's manual methodology prioritises non-destructive proof-of-concept exploitation. We coordinate testing windows, exclude denial-of-service techniques unless explicitly scoped, and use authenticated test accounts where possible. Where production-impacting test cases are required (for example, deserialization gadget validation), explicit written authorisation is obtained as part of the rules-of-engagement document.
Do you sign NDAs and provide proof of insurance?
Yes. CyberFortify operates under mutual NDAs on every engagement, carries professional indemnity insurance, and can complete vendor onboarding paperwork (TPRM questionnaires, security addenda, DPAs) ahead of work beginning.
How often should we run a web application penetration test?
The widely accepted baseline is annual, with an additional engagement triggered by major change - new authentication provider, tenant model rollout, payment processor switch, monolith-to-microservice migration, or a new product line. PCI DSS Requirement 11.4.3 codifies this with the phrase "at least once every 12 months and after any significant change." Customers running quarterly release trains usually pair an annual deep pen test with continuous DAST and a private bug bounty between engagements.
Is the testing internal, external, or both?
For most SaaS web applications, "external" and "internal" are not the right axes - the application is reachable from the public internet, but its authenticated surface is what matters. CyberFortify tests both unauthenticated and authenticated paths in the same engagement. For network-segmented internal admin consoles or VPN-gated tools, we set up a tester VPN account or jump host. For pure on-premises infrastructure, see our network penetration testing service.
Are tests performed remotely or on-site?
Remote, by default. CyberFortify is a Bahrain-headquartered firm and the testing team operates from secured offices and clean test environments. On-site testing is available on request for regulated environments where remote access is restricted, and is included where required by contract.
Who performs the test - will it be senior engineers or juniors?
Every CyberFortify web application penetration testing engagement is led by a senior offensive security engineer with multiple years of dedicated app-sec experience and active offensive certifications (OSCP, OSWE, BSCP or equivalent). We do not staff junior testers as engagement leads. The senior lead is named in the engagement letter and is the same person who delivers the report walkthrough.
What happens if you find a critical vulnerability mid-engagement?
Critical findings (CVSS 9.0+) are disclosed within 24 hours of validation through a pre-agreed secure channel, regardless of where we are in the engagement timeline. The intent is to give your engineering team a head start on remediation while testing of the rest of the application continues. The full writeup follows in the final report.
What does the report look like - can I see a sample?
Yes. CyberFortify can share a redacted sample report under NDA showing the full structure: executive summary, methodology statement, full finding writeups with CVSS v3.1 scoring, reproduction steps and evidence, remediation guidance, and the compliance evidence pack mapping. Request a sample report as part of the scoping conversation.