Case Study: API Penetration Testing

Case Study: API Penetration Testing

Application programming interfaces sit directly between untrusted client input and business-critical server-side functions. An earlier remediation can make an error quieter, strip one payload shape or add new response headers while still leaving the API vulnerable to the underlying attack.

This case study outlines a ProCheckUp API penetration test followed by a targeted vulnerability verification test for an international company. The assessment examined whether the vulnerability remediation genuinely broke the original attack paths across controller dispatch, query construction, input validation, stored content, error handling, response minimisation and HTTP security controls. 

Overview

An international company commissioned ProCheckUp to assess the administrative API supporting its SaaS management platform. After the original assessment identified a series of security weaknesses, ProCheckUp was asked to retest seven selected issues and determine whether the implemented changes had closed the original attack paths.

The verification phase did not rely on developer statements or code-change descriptions. ProCheckUp repeated the relevant request patterns, compared the resulting server and application behaviour, tested whether residual effects could still be chained, and assigned a defensible verification state to each finding.

The targeted retest recorded two resolved, three partially resolved and two unresolved issues. Three additional original issues were outside the verification scope and remained explicitly marked not tested.

Engagement at a glance

• - Original API penetration test followed by targeted remediation verification
• - Authenticated management-user perspective using controlled request manipulation
• - Seven findings replayed against the remediated API
• - Two issues verified as resolved
• - Three issues assessed as partially resolved
• - Two issues remained unresolved
• - Three additional findings were not included in the retest
• - CVSS version 3.1 ratings preserved from the source assessment

Challenge

API verification had to distinguish a complete security fix from changes that reduced visible impact while preserving the underlying vulnerability.

Code change versus attack-path closure

Generic errors, tag stripping or additional headers can improve resilience without necessarily removing the original route into dynamic dispatch, query construction or unsafe content handling. Closure therefore required the original attacker-controlled behaviour to fail under replay.

One trust boundary across API and application

The API primarily returned structured data, but parts of the platform also supported rich content that was later rendered by the management application. Input validation, API response handling and browser execution therefore had to be considered as one connected security boundary.

Framework behaviour required manual calibration

Dynamic model methods, positional query binding and exception handlers produced unusual effects. ProCheckUp had to separate demonstrated impact from dangerous but unchained functionality and avoid converting technical possibility into an unsupported claim of exploitation.

Targeted rather than exhaustive verification

Seven issues were selected for replay. The verification phase was not an exhaustive reassessment of every API route, role, business flow or original finding.

Assessment Scope

The public case study generalises all original routes, models, field names and platform identifiers while retaining the assessment logic. Testing concentrated on:

• - API request handling: parameters, JSON structures, field names, operators and values used by administrative functionality
• - Controller and method dispatch: whether client input could influence controller selection or invoke public and inherited model methods
• - Query construction: structural input, positional placeholders, dynamic columns and the boundary between parameter movement and proven injection
• - Input and content validation: field-specific character rules, HTML handling, output encoding and rich-content customisation
• - Error handling: whether exceptions exposed file, query, schema, model or code information
• - Response minimisation: excessive object fields, authentication secrets, recovery material and payment-related values
• - HTTP security controls: cache policy, transport protection, framing, content-type handling, referrer policy, permissions and Content Security Policy
• - Verification coverage: explicit separation of resolved, partial, unresolved and not-tested findings

Solution

ProCheckUp treated every selected finding as a security hypothesis that had to fail under controlled replay before it could be closed.

The assessment followed four stages:

1. Reproduce: repeat the original request pattern, payload class and affected function using the agreed authenticated context.
2. Compare: measure changes in response content, stored data, browser behaviour, method invocation and server-side exceptions.
3. Chain: determine whether residual behaviour could still support disclosure, validation bypass or follow-on exploitation.
4. Classify: record the result as resolved, partially resolved, unresolved or not tested, with an explicit evidence boundary and next action.

Four states were kept separate. Resolved meant the tested behaviour no longer succeeded. Partially resolved meant immediate impact was reduced but residual behaviour remained. Unresolved meant the original primitive could still be reproduced. Not tested meant the verification exercise produced no new conclusion.

Verification Status

The detailed issue matrix in the supplied verification report recorded the following results:

• - Dynamic dispatch and unintended method invocation — High, CVSS 7.7: Unresolved
• - Stored cross-site scripting — High, CVSS 7.6: Resolved
• - SQL query parameter-position manipulation — High, CVSS 7.4: Partially resolved
• - Lack of granular input validation — Medium, CVSS 6.5: Unresolved
• - Verbose error messages — Medium, CVSS 4.3: Partially resolved
• - Sensitive data returned in API responses — Medium, CVSS 4.3: Resolved
• - Missing or misconfigured security headers — Low, CVSS 3.1: Partially resolved

Not included in the targeted retest

• - Wildcard TLS certificate use
• - Version disclosure in HTTP response headers
• - Non-enforcement of MFA or TOTP

These three items must not be interpreted as resolved, accepted or closed. No verification conclusion was drawn for them during the targeted exercise.

Residual Vulnerabilities Identified

The remaining issues were concentrated around client influence over code paths, structural query input, inconsistent field validation and information-rich responses.

Unintended method invocation remained possible — High, CVSS 7.7

By modifying a supplied field value, the tester could still invoke public methods inherited by the relevant model, including a diagnostic method. The returned output exposed database-schema and code-context information.

Evidence boundary: unintended code execution and information disclosure were demonstrated, but the source assessment did not identify a complete useful exploitation chain from this primitive.

Recommendation: avoid dynamic invocation unless it is essential. Where it is required, enforce role-, controller-, model- and method-specific allow-lists before invocation.

Query-placeholder manipulation was quieter, not closed — High, CVSS 7.4

Earlier testing showed that attacker-controlled structural input could shift positional placeholders during query construction. Retesting reduced the query detail returned to the user, but invalid-column and placeholder-specific responses remained distinguishable.

Evidence boundary: structural query behaviour remained observable; a working SQL-injection chain was not established.

Recommendation: reject, escape or encode placeholder characters and other structural tokens before values can influence dynamic identifiers or query compilation.

Field validation remained too permissive — Medium, CVSS 6.5

Changes prevented the previously successful stored-script payload, but fields still accepted characters beyond those required for their expected data types. The same validation weakness connected to the dispatch, content and error-handling findings.

Recommendation: use server-side, per-field allow-lists; reject undocumented input; validate controller and method names against known-good values; and replace arbitrary HTML customisation with structured data wherever practical.

Error handling remained partially resolved — Medium, CVSS 4.3

Several responses became less verbose, but diagnostic method invocation could still return schema and code information. Distinguishable error classes also continued to reveal which internal condition had occurred.

Recommendation: return one generic client-safe exception message, retain full diagnostic detail only in protected server logs, and disable verbose error output outside isolated development environments.

Security headers improved but remained incomplete — Low, CVSS 3.1

The retest observed additional transport, content-type, framing, referrer and permissions controls. However, cache directives could still permit local storage, while Content Security Policy remained in report-only mode and included unsafe directives and broad external sources.

Recommendation: use no-store for sensitive responses, enforce rather than merely report the Content Security Policy, remove unsafe directives where feasible and restrict third-party sources as narrowly as possible.

Verified Closures

The retest also produced evidence that two material weaknesses had been closed in the tested contexts.

Stored cross-site scripting — Resolved, High, CVSS 7.6

Previously vulnerable user-data fields stripped submitted HTML tags, and the tested rich-content workflow no longer executed the stored payload. The assessment therefore marked the selected stored-script path as resolved.

Follow-up: verify that the same data is safely handled in every other application view, export, notification or downstream consumer in which it may be rendered.

Sensitive data in API responses — Resolved, Medium, CVSS 4.3

The tested user response no longer returned TOTP secrets or recovery material, and the tested order response omitted the previously exposed payment-key value.

Follow-up: return explicit field projections rather than complete database objects and ensure secrets can be written or rotated without ever being retrieved through ordinary API responses.

Authorised Residual-Risk Model

The following sequence explains how the confirmed residual behaviour could combine, while preserving the distinction between demonstrated evidence and potential downstream impact:

1. Authenticated management context — test precondition: the engagement began with authorised access to the management API.
2. Structural input manipulation — confirmed: field names, operators and content were modified beyond their intended data types.
3. Unintended method invocation — confirmed: dynamic dispatch reached an inherited diagnostic method not intended for the user.
4. Technical-information disclosure — confirmed: the response exposed schema and code-context information useful for reconnaissance.
5. Query influence — partially confirmed: placeholder movement was observed, but SQL injection was not achieved.
6. Useful callable functionality — potential: another exposed method might act on URL, JSON or header input and produce greater impact; this was not proven.
7. Stored-script execution or secret retrieval — blocked in the tested paths: the selected XSS and excessive-response-data behaviours no longer succeeded.

This is an authorised residual-risk model, not evidence of a real-world compromise. Testing used approved accounts and controlled data. The assessment did not establish production data theft, arbitrary database access or a complete exploit chain from the residual method-invocation behaviour.

Control Effectiveness and Assessment Boundaries

Positive controls verified

• - Previously vulnerable user-data HTML was stripped in the tested workflow
• - Dangerous rich-content attributes no longer executed in the tested manager view
• - TOTP secrets and recovery material were omitted from the tested response
• - The tested payment-key value was removed from API output
• - Several additional response-security headers had been introduced
• - Some database errors were replaced with shorter, less revealing messages

Limitations and publication boundaries

• - Only seven selected findings were retested
• - The wildcard-certificate, version-disclosure and MFA/TOTP issues were not verified
• - Every route, role and business function was not exhaustively reassessed
• - A useful exploitation chain from arbitrary method invocation was not established
• - SQL injection was not proven
• - The supplied report contains draft annotations and should be reconciled with the final signed version before publication
• - The source material does not confirm that later remediation was completed or independently retested

The case study therefore reports issue-level verification results, not a blanket statement that the complete API or platform was secure.

Outcome

The engagement gave the customer a precise remediation baseline rather than a single pass-or-fail judgement for the whole API.

Two material weaknesses were demonstrably closed, providing evidence that targeted changes to stored-content handling and response minimisation were effective in the tested contexts. The same replay process showed that dynamic dispatch and granular input validation remained open, while query manipulation, error handling and response headers had improved without reaching complete closure.

By separating resolved, partially resolved, unresolved and not-tested states, ProCheckUp gave development, product and security teams a clear sequence for engineering work, a defensible record for stakeholders and concrete negative tests for future releases.

Publication boundary: this case study does not state that the complete remediation programme was subsequently implemented or independently retested.

Remediation Priorities

Immediate attack-path closure

• - Remove dynamic method invocation unless there is a documented business requirement
• - Implement role-, controller-, model- and method-specific allow-lists
• - Reject placeholder characters and structural tokens in dynamic query identifiers
• - Return one generic client-safe exception while preserving protected server-side diagnostics
• - Review logs for unexpected diagnostic-method calls and repeated invalid-field probes

Engineering hardening

• - Apply server-side allow-lists for every field and data type
• - Version API schemas and reject undocumented fields and operators
• - Return explicit response projections rather than complete database objects
• - Replace embedded HTML with structured customisation data where feasible
• - Use a maintained DOM-purification component and sandboxed rendering where rich HTML is unavoidable
• - Apply no-store caching and move CSP from report-only to enforced operation
• - Restrict external sources and remove unsafe CSP directives where practical

Sustained API assurance

• - Turn every finding into an automated negative regression test within CI/CD
• - Add security unit tests around controller dispatch and query-builder behaviour
• - Retest the wildcard-certificate, version-disclosure and MFA/TOTP findings
• - Repeat independent API testing after significant framework, schema or business-logic changes
• - Track partial findings until replay demonstrates that the original primitive fails end to end

The Core Security Lesson

A fix is closed only when the original attack path fails end to end.

Changing an error message, stripping one payload shape or adding a report-only header can reduce immediate impact without removing the trust-boundary weakness. Strong API assurance follows attacker-controlled input through dispatch, query logic, data handling and the final response returned to the consumer.

The correct question is not simply:

“Was a patch deployed?”

It is:

“Can the same attacker-controlled request still reach the unintended code path or disclose the protected data?”

How ProCheckUp Helps

ProCheckUp’s API Penetration Testing and Verification services assess the complete relationship between client-controlled input, server-side business logic, application rendering and remediation evidence. Support can include:

• - API endpoint, schema and attack-surface mapping
• - Authentication, authorisation and function-level access-control testing
• - Parameter, JSON, header and structural-input manipulation
• - Business-logic, query-construction and mass-assignment assessment
• - Input validation, rich-content and stored-script testing
• - Excessive-data and sensitive-response review
• - Error handling, caching, CORS and response-header assessment
• - API-to-application and API-to-cloud attack-path validation
• - Targeted remediation verification and issue replay
• - Regression-test design for CI/CD and future releases

Related services include Application PenTesting, Web Application Penetration Testing and Penetration Testing.

Conclusion

This engagement demonstrated why remediation verification must replay the original attack rather than confirm only that code changed. The customer had made meaningful progress: stored-script execution and sensitive-response exposure were closed in the tested paths, while several other behaviours had been reduced or hardened.

The remaining work was concentrated in the deeper API contract—dynamic dispatch, structural query input, field-specific validation, error consistency, cache control and enforceable browser policy. Closing those primitives and converting the replay cases into automated regression tests would give the customer a repeatable standard for future API releases.

To discuss an API penetration test, business-logic assessment or targeted remediation-verification exercise, contact ProCheckUp.