Short answer
A Helix web application penetration test checks whether an attacker can reach data or actions they should not. Most of the time goes to access control, tenant isolation, and business logic, because that is where Critical and High findings come from. Header and TLS checks still run, but they are the floor, not the test.
What we test
Before testing, agents log in, map every endpoint by role, and rank the surface by what an attacker would want: other tenants' data, server-side fetches, state-changing APIs, payment and signup, identity flows, and webhooks. Testing then runs in parallel lanes:
| Area | What the agents look for |
|---|---|
| Access control and IDOR | Reading or changing another user's or tenant's records, role escalation, admin functions reachable by ordinary users |
| Authentication and sessions | Login, password reset, MFA, SSO and OAuth flows, session fixation, token handling, logout and expiry |
| Business logic | Skipped steps, negative quantities, replayed actions, race conditions, limits that hold in the UI but not in the API |
| Injection and XSS | SQL, NoSQL, command and template injection, stored and reflected XSS, Markdown and HTML rendering |
| SSRF | URL previews, imports, webhooks, PDF renderers, and any feature that makes the server fetch something |
| Client side | CORS, CSP, postMessage handlers, open redirects, CSRF, secrets in JavaScript bundles |
| AI features | Prompt injection, tool and MCP misuse, and data leaks in embedded LLM assistants and agents |
| Deployment edge | Exposed dev and ops tooling, internet-facing third-party components with known CVEs, TLS and header hygiene |
The web vulnerability field guide explains each class with safe examples and fixes.
How the test runs
- Rules of engagement. Your owner or admin signs them in the portal. The signature covers the exact hosts, exclusions, and test window. No traffic is sent before it exists.
- Recon and threat model. An authenticated crawl builds a map of hosts, endpoints, methods, roles, and parameters. The agents rank it by value and write down which trust boundaries they observed and which they inferred.
- Parallel testing. Each testing lane runs as its own agent in an isolated sandbox, with the coverage areas above. Every lane records what it tried and how far it got, including the attacks that failed, so coverage is evidence and not a claim.
- Independent verification. A separate agent replays each candidate finding and argues the strongest case against it. If it cannot reproduce the issue, the finding is dropped or sent to a human.
- Attack chains. One pass looks at all findings together. Two Lows that combine into account takeover are reported as the chain, rated by the step actually reached.
- Live escalation. Confirmed High and Critical findings reach you as soon as they are verified. If you fix during the test, the fix is re-verified inside the engagement.
Black, gray, or white box
Black box starts with no accounts and tests what an outsider can reach. Gray box adds test accounts and context, which is what most SaaS products need, because it reaches the authenticated surface where tenant and role bugs live. White box adds the source code: a code review pass aims the dynamic testing, and findings point to the exact code path.
For gray and white box, provide two accounts for each role, in two separate tenants if your product is multi-tenant. Source archives are uploaded in the portal and pinned by SHA-256 to the signed scope. See black vs gray vs white box testing for a longer comparison.
Testing production safely
- Detect-only by default. State-changing probes need explicit permission in the rules of engagement.
- No denial of service, no unbounded brute force, and no destructive actions outside records the test itself created.
- Every request passes a scope guard with a host allowlist that also checks redirects. Out-of-scope hosts are never contacted.
- Secrets, tokens, and personal data are masked before they reach the findings or the report.
- Agents run on private inference. Your code, traffic, and findings are not sent to a third-party model provider.
- Operators can stop the test at any time, and every lifecycle change is written to an append-only audit log.
What you get
Findings appear in the Helix PTaaS portal as tickets with a severity, status, replayable evidence, and a fix. Severity uses five ranks, Critical to Info, and each rating names the factor that drives it. Reports cover methodology, scope, coverage with explicit negatives, findings, and remediation status. Technical, executive, and compliance-mapped versions are available, along with an attestation letter and SARIF export.
Pricing and retesting
| Access | Price | Fits |
|---|---|---|
| Black box | From $7,000 USD | External attack surface of a well-bounded application |
| Gray box | From $10,000 USD | Authenticated, multi-role SaaS testing |
| White box | From $10,000 USD | Source-assisted testing, priced on codebase size |
Retesting is free and unlimited for every engagement. When a fix ships, mark the finding ready for retest and the agents attack it again. Larger applications are scoped before testing starts. The penetration testing cost guide explains what drives price across the market.
Frequently asked questions
How much does a web application penetration test cost?
Helix black-box tests start at $7,000 USD and gray-box and white-box tests at $10,000 USD. The final price depends on the number of roles, endpoints, and integrations, and for white box on codebase size. Retesting is free and unlimited for every engagement. Larger applications are scoped and priced before testing starts.
Is an AI penetration test as good as a manual one?
It depends on the provider. A scanner with an AI label produces the same noise as before. Helix agents log in, map every role, rank the surface by value, and spend most of the run on access control and business logic, which is where serious findings come from. A separate agent must reproduce each finding, and humans oversee the run and judge authorization and business-logic questions.
Do you test while logged in?
Yes. An authenticated crawl is mandatory for gray-box and white-box tests. We ask for at least two accounts per role, ideally in two different tenants, so we can test whether one customer can read or change another customer's data.
Can you test our production environment?
Yes, within the rules of engagement you sign. Testing is detect-only by default: no denial of service, no unbounded brute force, and no destructive actions outside test records the engagement creates. Every request goes through a scope guard that blocks hosts you have not authorized, including redirects. Staging is a good choice when you want state-changing tests.
Will the report satisfy SOC 2, ISO 27001, or PCI DSS?
Reports record scope, methodology, coverage, findings, severity, and remediation status, and can be mapped to SOC 2, ISO 27001, PCI DSS, HIPAA, or HITRUST. Your auditor decides what evidence they accept, so share the report outline with them early if you have a deadline.
How long does a web app pentest take?
Testing starts once scope, the signed rules of engagement, and test access are confirmed. Confirmed High and Critical findings are reported to you as soon as they are verified, not held for the final report.