Point-in-Time Penetration Testing
Raxis Strike
A fixed window, full depth, a report you can hand to an auditor.
Best when you have a launch, an audit, or a first test to get right.
Works as designed. That’s the bug.
Your form shows two fields. A senior U.S. engineer sends a third the server never should have trusted, and a standard user saves themselves as admin. When we reach what matters, we leave a card.
The browser sends
POST /api/account/me
{
"name": "Ada Lovelace",
"email": "ada@acme.io"
} Two fields. All the form has.
The attacker edits it
POST /api/account/me
{
"name": "Ada Lovelace",
"email": "ada@acme.io", "role": "admin"
} One line added, in transit.
The server trusts it
200 OK role updated
Nothing replaces skill. Illustrative request. Valid schema, valid token, a field it should have refused.
Login, registration, and recovery flows. Injection, bypass, session fixation, and the endpoints nobody locked.
Limited permissions, pushed upward. Vertical escalation, IDOR, and the authorization check that was never written.
Full access, end to end. The misconfigurations and logic gaps an admin can break the system with, on purpose or by accident.
One customer’s session, token, or input reaching another customer’s data, through any path. Quiet failures, loud when public.
A01:2025
Horizontal and vertical escalation, IDOR, forced browsing, JWT manipulation, and SSRF against your internal services.
A02:2025
Default credentials, exposed admin panels, verbose errors, missing headers, open storage.
A03:2025
Compromised dependencies, dependency confusion, tampered pipelines, tested in your application’s actual context.
A04:2025
Plaintext where there should be none, weak TLS, predictable tokens, broken key handling.
A05:2025
SQL, NoSQL, command, LDAP, and XSS. How much your application trusts what it is given.
A06:2025
Missing rate limits, abusable workflows, and trust boundaries that should not exist. The application you meant to build, tested against the one that shipped.
A07:2025
Credential stuffing exposure, weak MFA enrollment, predictable sessions, and reset flows that leak.
A08:2025
Insecure deserialization, unsigned updates, third-party scripts with no integrity check.
A09:2025
The events you do not log, and the alerts that never fire while we are inside.
A10:2025
Access control that holds on the happy path and fails open on the error path.
01
Black, grey, or white box. Roles, environments, rules of engagement, and anything that needs care.
02
Automation does reconnaissance and known-CVE checks. Engineers do exploitation, logic abuse, and chaining. That is most of the value.
03
Criticals and highs land in Raxis One with proof and a fix as we find them. The engineer testing your app is the one you talk to.
04
You fix. We confirm, at no extra cost, and issue the clean report.
Raxis Strike
A fixed window, full depth, a report you can hand to an auditor.
Best when you have a launch, an audit, or a first test to get right.
Raxis Attack
Unlimited manual testing all year, findings live the moment we confirm them.
Best when you ship every sprint and the application never sits still.
Every finding with proof, reproduction steps, impact, and a fix, from the engineer who found it.
A board-readable read on the risk and the actions that move it.
Walk the findings with the engineer who did the work.
We verify the fix and issue a clean report, at no extra cost.
Our stories are based on real events encountered by Raxis engineers. Some details have been altered or omitted to protect customer identities.
Running the usual unauthenticated checks against a small e-commerce site, our pentester found that the login form took a single quote and kept going. A classic ’ OR 1=1 opened customer accounts, then administrator accounts.
He fed the vulnerable request to SQLMap. It enumerated the databases, then the tables, then pulled the whole thing: encrypted passwords and personal information for every user, admins and customers alike.
It was a critical, so the customer heard about it that day, with the fix. They patched it inside the testing window and our pentester confirmed the remediation before the engagement closed. He did log in as the CEO first, for the screenshot in the report.
Web application penetration testing is a manual security assessment in which engineers attempt to exploit vulnerabilities in your web application the way an attacker would. It goes beyond automated scanning to find business logic flaws, broken access control, authentication weaknesses, and chained exploits that scanners can't reason about.
A vulnerability scan compares your application against a database of known issues. A penetration test exploits those issues, chains them together, and finds the ones that aren't in any database. Scanners are useful inputs to a pentest. They are not a substitute for one.
Customer-facing portals, internal applications, SaaS platforms, single-page and server-rendered apps, multi-tenant systems, complex role hierarchies, applications behind SSO, and applications that depend on third-party APIs. We have tested in nearly every framework on the market.
Grey box is the most common and usually the most useful. You provide test accounts at each role level, and we work from there. Black box is closer to a real external attack but slower. White box, with source code review, goes deepest and is most valuable for high-stakes or pre-launch applications.
We work with you to scope around production safety. Most engagements run against staging or pre-production environments that mirror production. When production testing is required, we coordinate timing, throttle our activity, and avoid destructive techniques unless explicitly authorized.
A detailed technical report with proof-of-concept evidence and remediation guidance, an executive summary suitable for board and audit use, real-time findings in the Raxis One portal during the engagement, and a remediation retest at no extra charge once your team has implemented fixes.
At minimum, annually and after any major release, framework upgrade, or change to authentication or authorization. For applications under continuous development, a once-a-year cadence leaves long windows of unvalidated change. Continuous testing through Raxis Attack closes that gap.
Yes. Multi-tenant testing is one of our specialties. We validate that customer A cannot see, modify, or impact customer B's data through any path, including direct object references, shared resources, indirect channels, and abuse of administrative interfaces.
Web application engagements cover the APIs your application directly depends on. For dedicated, comprehensive API testing across REST, GraphQL, SOAP, and gRPC interfaces, including ones not exposed through a web UI, see our API Penetration Testing service.
Most engagements run one to two weeks of active testing depending on the size of the application, the number of roles, and the complexity of its workflows. Critical findings reach you in real time through Raxis One, and the full report follows within days of testing completion.
Cost scales with the size and complexity of the application: the number of roles, workflows, and endpoints in scope is the biggest driver. Be wary of quotes that seem too low; they usually mean an automated scan with a pentest label. Contact us for a quote scoped to your application.
Senior US-based Raxis engineers holding certifications such as OSCP and OSWE. Your test is never outsourced, and the engineer who exploits your application is the same person who writes your report and walks you through it.
Yes. We regularly test applications behind SAML, OAuth, and OIDC single sign-on as well as multi-factor authentication. We coordinate test accounts and access during scoping, and the SSO and MFA flows themselves are part of what we attack.
AI features in scope are tested as part of the application, including prompt injection and data exposure through LLM integrations. For deep testing of AI systems themselves, see our AI and LLM Penetration Testing service.