What We Test: Applications, APIs, Authentication, Infrastructure

Security assessments are defined by their scope. A test that only covers the web interface misses the API. A test that only covers the API misses the authentication layer. A test that covers both but ignores the cloud infrastructure misses the storage bucket that's publicly readable.

Comprehensive coverage means testing every layer that an attacker can reach. Here's what we test, what we find, and why each target type matters.

Web Applications

Web applications are the primary interface between an organization and its users, customers, and partners. They're also the primary attack surface — every feature, form, and page is an entry point for exploitation.

What We Look For

Access control enforcement. Every page, function, and data retrieval is tested for proper authorization. Can a regular user reach admin pages? Can User A view User B's data? Can read-only accounts perform write operations? Access control flaws are the #1 web vulnerability class and appear in the majority of our assessments.

Input handling. Every field, parameter, header, and cookie that accepts user input is tested for injection vulnerabilities: SQL injection, cross-site scripting (stored, reflected, and DOM-based), server-side template injection, command injection, and path traversal. We test with context-aware payloads — not generic wordlists — informed by the application's technology stack.

Business logic. Checkout flows, discount systems, referral programs, multi-step wizards, and state-dependent operations are tested for workflow bypass, parameter manipulation, race conditions, and abuse scenarios. These are the vulnerabilities that scanners cannot detect.

Session management. Token generation randomness, cookie security attributes, session fixation, timeout enforcement, concurrent session handling, and logout completeness. Weak session management is the foundation for account takeover attacks.

File handling. Upload functionality is tested for unrestricted file types, path traversal in filenames, server-side execution of uploaded content, storage location security, and download authorization. A single unrestricted upload endpoint can lead to remote code execution.

Error handling and information disclosure. Stack traces, debug output, verbose error messages, exposed configuration details, and server version headers all provide attackers with intelligence that accelerates exploitation.

Common Findings

Across our assessments, the most frequent web application findings are: broken access control (both horizontal and vertical), cross-site scripting in stored contexts, insecure direct object references, missing security headers, session management weaknesses, and business logic flaws in financial operations. Of our 320+ critical findings, a significant portion originated from web application testing.

Industries We See This In

Every industry that operates a web application — but the stakes vary. FinTech platforms process financial transactions where access control failures have direct monetary impact. Healthcare applications handle protected health information where data exposure triggers regulatory consequences. Enterprise SaaS platforms serve multiple tenants where cross-tenant data leakage is an existential risk. Defense and government applications handle classified or sensitive information where any unauthorized access is unacceptable.

REST and GraphQL APIs

APIs power modern applications. The web frontend, mobile apps, third-party integrations, and internal services all communicate through APIs. They're often the most direct path to sensitive data — and they frequently have weaker security controls than the web interfaces that consume them.

REST APIs: What We Look For

Broken Object-Level Authorization (BOLA). The API equivalent of IDOR. Endpoints that take resource identifiers — /api/v2/orders/12345 — are tested to verify that the requesting user is authorized to access that specific resource. BOLA is the #1 API vulnerability and it's alarmingly common.

Mass assignment. APIs that bind request parameters directly to internal data models can allow attackers to modify fields they shouldn't access. Sending "role": "admin" or "verified": true in a profile update request — if the API doesn't whitelist acceptable fields — can escalate privileges or bypass verification.

Excessive data exposure. APIs often return complete data objects, relying on the frontend to display only relevant fields. The full response — visible to anyone inspecting network traffic — may contain sensitive fields like internal IDs, email addresses, permission levels, or authentication tokens that the UI intentionally hides.

Rate limiting and resource consumption. APIs without rate limiting allow enumeration attacks, brute-force authentication, and data harvesting at scale. APIs without pagination or result limits allow denial-of-service through resource exhaustion.

Authentication and token handling. API key management, OAuth token validation, JWT implementation (algorithm confusion, signature verification, claim validation), and token lifecycle management.

GraphQL APIs: Additional Vectors

GraphQL introduces unique attack surface beyond what REST APIs present:

Introspection exposure. GraphQL's introspection system reveals the entire schema — every type, field, query, and mutation. In production, this hands attackers a complete map of the API. We test whether introspection is disabled or restricted and what the exposed schema reveals.

Query depth and complexity attacks. GraphQL's nested query capability allows deeply nested requests that consume exponential server resources. A query that nests relationships 20 levels deep can crash or severely degrade the server. We test for depth limits, complexity scoring, and query cost analysis.

Batching abuse. GraphQL supports sending multiple operations in a single request. This can bypass rate limiting (send 1,000 login attempts in one request), circumvent brute-force protections, and amplify any vulnerability that affects individual operations.

Authorization at the field level. GraphQL resolvers may enforce authorization on some fields but not others within the same type. A user query might properly restrict email but expose internalNotes or passwordResetToken. We test authorization on every field, not just every type.

Common API Findings

BOLA and excessive data exposure are the most prevalent. Mass assignment appears in roughly one in five API assessments. Missing or inadequate rate limiting is nearly universal. GraphQL-specific issues — introspection exposure, missing depth limits, and field-level authorization gaps — appear in the majority of GraphQL assessments.

Authentication and Identity

Authentication is where account takeover chains begin. A flaw in login, registration, password reset, or session management gives attackers the keys to user accounts — and everything those accounts can access.

OAuth 2.0 and OpenID Connect

OAuth implementations are complex and error-prone. We test:

• Redirect URI validation — can the redirect be manipulated to send authorization codes or tokens to an attacker-controlled domain? Partial matching, open redirect chaining, and path traversal in redirect URIs are common bypass vectors.
• State parameter handling — is the state parameter present, validated, and tied to the user's session? Missing state validation enables CSRF-based account linking attacks.
• Token handling — are tokens properly scoped, time-limited, and validated? Are refresh tokens rotated after use? Can tokens be replayed across different clients?
• Scope escalation — can a client request broader permissions than it was granted during authorization? Does the authorization server properly restrict scope to the approved set?

SAML and SSO

SAML-based Single Sign-On introduces its own vulnerability patterns:

• Signature validation — does the service provider properly validate the SAML assertion's signature? Signature wrapping attacks can inject unauthorized assertions into validly signed responses.
• Assertion manipulation — can attributes within the assertion (email, role, organization) be modified to impersonate other users or escalate privileges?
• Replay and expiration — are assertions time-limited and protected against replay?

Password Reset Flows

Password reset is one of the most consistently vulnerable features we encounter:

• Token predictability — are reset tokens generated with sufficient randomness, or can they be predicted or brute-forced?
• Token leakage — does the token appear in referrer headers, URL parameters visible in logs, or responses to other endpoints?
• Account enumeration — does the reset flow reveal whether an email address is registered through different response messages or timing differences?
• Token lifecycle — does the token expire after use? After a time limit? After a new token is generated? Tokens that remain valid indefinitely are tokens that can be discovered and used at any point in the future.

Multi-Factor Authentication

MFA is only as strong as its implementation:

• Bypass via fallback — can MFA be skipped by using a different authentication path (API instead of web, mobile instead of desktop)?
• Code brute-forcing — are TOTP or SMS codes protected by rate limiting and lockout? A 6-digit code has only 1 million possibilities.
• Recovery code handling — are recovery codes single-use, properly stored, and invalidated after MFA reconfiguration?

Common Authentication Findings

Password reset token leakage, OAuth redirect URI bypass, missing account lockout, session tokens with insufficient entropy, and MFA bypass through alternative authentication paths. These findings appear consistently across industries, from early-stage startups to mature enterprise platforms.

Cloud Infrastructure

Cloud infrastructure has become a primary attack surface. Misconfigured cloud services expose data, provide unauthorized access, and create lateral movement opportunities that didn't exist in traditional architectures.

What We Look For

Identity and Access Management (IAM). Overly permissive IAM policies, unused roles with elevated permissions, cross-account access misconfigurations, and service accounts with broader permissions than their function requires. IAM is the foundation of cloud security — when it's misconfigured, every service it protects is at risk.

Storage permissions. Object storage buckets and blobs with public read access, public write access, or predictable naming that enables enumeration. We've found production databases backed up to publicly readable storage, application secrets stored in world-accessible buckets, and customer data exposed through misconfigured CDN origins.

Network configuration. Security groups and network ACLs with overly broad ingress rules, exposed management ports (SSH, RDP, database ports), and missing egress restrictions that allow data exfiltration.

Serverless and container security. Lambda/Cloud Function permissions, environment variable exposure, container image vulnerabilities, orchestration platform misconfigurations, and secrets management in containerized environments.

Cross-service communication. Internal service-to-service authentication, message queue permissions, event bus configurations, and shared resource access patterns. In microservice architectures, a compromise of one service should not automatically grant access to all others.

Industries Where Cloud Findings Are Critical

Crypto and FinTech platforms running on cloud infrastructure face regulatory and financial consequences from cloud misconfigurations. Healthcare organizations storing patient data in cloud services must comply with strict data protection requirements. SaaS platforms operating multi-tenant architectures on cloud infrastructure face existential risk from cross-tenant cloud access.

Mobile Backends

Mobile applications communicate with backend APIs that often receive less security scrutiny than their web counterparts. The assumption that traffic is "protected" because it comes from a mobile app — an app the organization controls — leads to weaker security controls on the backend.

What We Look For

API security parity. Every security control that exists on the web API should exist on the mobile API. In practice, we frequently find that mobile endpoints lack rate limiting, have weaker authentication requirements, expose more data in responses, and skip authorization checks that are enforced on the web version.

Certificate pinning bypass. We assess whether the mobile application implements certificate pinning and whether the backend assumes pinning provides security guarantees. Certificate pinning is a client-side control — the backend must enforce its own security regardless of whether the client validates certificates.

Transport security. TLS configuration, certificate validation, and protection of data in transit. Mobile applications on shared networks (coffee shop WiFi, corporate networks) face interception risks that make transport security critical.

Client-side data exposure. Sensitive data stored in local databases, preferences, logs, or cached files on the device. While this is primarily a mobile application concern, it informs backend testing — if the mobile app caches authentication tokens insecurely, the backend's token lifecycle management becomes more critical.

Common Mobile Backend Findings

Weaker authorization enforcement compared to web APIs, missing rate limiting on authentication endpoints, excessive data exposure in API responses, and reliance on client-side controls (like certificate pinning) as substitutes for server-side security.

Coverage That Matches the Threat

Attackers don't limit themselves to one layer. A real attack might begin with cloud reconnaissance, pivot through an exposed API, exploit an OAuth implementation flaw, and chain it with a broken access control vulnerability to reach sensitive data.

Testing each layer in isolation misses these chains. Our assessments cover the full stack — web applications, APIs, authentication, infrastructure, and mobile backends — because that's what a thorough attacker would target. Over 400 targets assessed and 1,400+ findings documented, and the engagements that produce the most critical results are always the ones with comprehensive scope.

Need your application tested for security vulnerabilities? Get in touch.