Every way into your app, tested like an attacker would.

We start with what an attacker can actually reach.

Every web assessment begins with external reconnaissance. We build an attack-surface map before moving into deeper testing.

• Domains and subdomains
• DNS
• IP addresses and ports
• Web applications
• APIs and undocumented endpoints
• JavaScript assets and source maps
• Authentication endpoints
• OAuth/OIDC infrastructure
• Development and staging environments
• Public storage
• Exposed files and secrets
• Administrative interfaces
• Public services
• Cloud-exposed assets

Can an attacker become someone they're not?

These aren't scanner checks. We've found real account-takeover paths through registration, OTP enumeration, OAuth flows and redirect handling.

• Login
• Registration
• Password reset
• Account recovery
• Session management
• Session invalidation
• OAuth/OIDC
• JWTs
• API keys
• MFA where present
• Rate limiting
• Account enumeration
• Token expiration and reuse
• Token scope
• Authentication logic

What can this user access that they shouldn't?

Testing includes manipulating identifiers, replaying and forging tokens, probing unauthorized routes and comparing access across privilege boundaries. Where the application supports it, we test with multiple users and tenants to verify that one customer cannot cross into another customer's data or permissions.

• IDOR / BOLA
• Object-level authorization
• Function-level authorization
• Role boundaries
• Admin vs user access
• Tenant isolation
• Cross-tenant access
• Hidden endpoints
• Direct object references
• API authorization
• Backend authorization controls

The bugs scanners don't understand.

Your application has rules. We try to break them. We've found payment bypasses, credit accumulation, invitation races and provisioning flaws that no automated tool would recognize as bugs.

• Payment bypasses
• Credit manipulation
• Account creation abuse
• Invitation races
• Workflow/state manipulation
• Race conditions
• Duplicate actions
• Rate-limit bypasses
• Client/server trust failures
• Password-reset abuse
• Role changes
• File workflows
• Subscription flows where relevant

APIs are attack surfaces, not documentation.

API discovery and inventory happen as part of every assessment. API testing is aligned with the OWASP API Security Top 10 (2023) and planned around the risks that apply to your API, not run as an item-by-item checklist.

• Authentication
• Authorization
• BOLA
• Function-level authorization
• Input validation
• Injection
• Excessive data exposure
• Rate limiting
• SSRF
• API inventory
• Shadow APIs
• Deprecated endpoints
• Method manipulation
• Content-type manipulation
• Parameter pollution
• GraphQL where present

Where input becomes instructions.

We actively test for injection paths including SQL injection, NoSQL injection and prompt injection. Additional injection classes are investigated where the application's technology and attack surface make them relevant.

• SQL injection
• NoSQL / operator injection
• Prompt injection

Can the server be turned against its own environment?

We test the server-side request flows that matter, and follow them as far as they go. We've demonstrated SSRF through a redirect bypass into cloud metadata in real assessments.

• SSRF
• Blind SSRF
• Redirect-based SSRF
• URL-validation bypasses
• Internal service access
• Cloud metadata access
• Webhook abuse
• URL previews
• File-fetching functionality
• Import mechanisms

What your cloud shows the internet.

External cloud exposure is part of standard testing.

• Public cloud services
• Public storage
• Cloud-hosted applications
• Cloud metadata exposure
• Exposed secrets
• External network exposure
• DNS
• TLS
• Staging environments
• Public administrative interfaces

Modern applications aren't just APIs anymore.

Where AI or agentic functionality exists, we test the tools, agents and trust boundaries behind it. Our assessments have found MCP dynamic-client-registration abuse, tool-authorization gaps, tool-filter bypasses, tool poisoning and system-prompt exposure. This isn't "AI-powered pentesting": it's people testing your AI.

• Prompt injection
• Indirect prompt injection
• System-prompt exposure
• Tool abuse
• Tool authorization
• Unsafe tool arguments
• Tool-filter bypasses
• MCP servers
• MCP tool permissions
• Dynamic client registration
• Cross-user data isolation
• Model/API-key exposure
• Agent-to-agent trust

Where your data actually lives.

We use the minimum evidence necessary to prove exposure. We never bulk-download customer data; sensitive storage findings are proven with listings and redacted samples.

• File uploads
• File type validation
• Path traversal
• Public storage
• Private storage controls
• Signed URLs
• Object-level authorization
• Sensitive data exposure
• Download endpoints
• Source maps
• Exposed files
• Secrets

The things surrounding the application.

Depending on the technology and scope:

• XSS
• CSRF
• CORS
• Clickjacking
• CSP
• Browser storage
• Client-side authorization
• Exposed API keys
• Source maps
• JavaScript secrets
• Security headers
• TLS
• Cookies
• Debug interfaces
• Error disclosure
• Admin interfaces
• Directory listing
• DNS
• Subdomain takeover
• Staging exposure
• Production/development separation

A finding is a starting point, not a result.

Don't just find SSRF: ask what it can reach. Don't just find an OAuth misconfiguration: ask whether it becomes account takeover. Don't just find a dangling subdomain: ask what it can intercept. These chains come from real Zentinel assessments.

• Dangling subdomain→JWT interception→Account takeover
• Registration flaw→Credential takeover→Merchant realm access
• Webhook SSRF→Redirect bypass→GCP metadata
• OAuth redirect weakness→Interception→Internal services
• MCP dynamic client registration→Phishing-grade client

Map. Enumerate. Attack. Chain. Prove. Fix. Verify.

Every finding needs reproduction, evidence, demonstrated impact, a CVSS score and remediation, and a human security engineer reviews it before delivery.

1. 01
   MAP

   Discover the attack surface.

2. 02
   ENUMERATE

   Identify identities, endpoints, permissions and trust boundaries.

3. 03
   ATTACK

   Probe the controls that matter.

4. 04
   CHAIN

   Follow weaknesses into realistic attack paths.

5. 05
   PROVE

   Reproduce the vulnerability and capture the minimum necessary evidence.

   POST /api/auth/register
   Host: [redacted]
   
   {
     "email": "founder@[redacted].com",
     "password": "[redacted]"
   }
   
   HTTP/1.1 200 OK
   
   "notice": "existing account merged"
   

   From a real finding: Signup form that reset anyone's password. Host, account and password are redacted; the rest is as captured.
6. 06
   FIX

   Give the engineering team a practical remediation path.

7. 07
   VERIFY

   Retest the fix and record the result.

Built on established frameworks, adapted to your attack surface.

Zentinel's testing methodology is built around established offensive-security frameworks and adapted to the application's actual attack surface.