This grey box API penetration test of a logistics platform’s partner API focused on webhook delivery, the feature that makes the platform connect to partner-supplied addresses. It confirmed server-side request forgery (SSRF): private IP addresses were blocked when entered directly, but the background delivery worker followed a redirect from a public endpoint to an agreed internal test endpoint without revalidating the destination.
| Engagement | Details |
|---|---|
| Scope | Partner API, webhook delivery, and asynchronous processing |
| Approach | Grey box |
| Effort | 6 tester-days, plus 1 tester-day for retesting |
| Retest | After six business days: the original redirect scenario, IPv4 and IPv6 destinations, multi-step redirects, and legitimate webhook deliveries |
Key takeaways
- Submitting a private IP address directly as a webhook destination was blocked; a redirect from a controlled public endpoint was not revalidated.
- A unique marker recorded by the internal test endpoint, together with the matching worker log entry, confirmed the connection.
- The report distinguished confirmed SSRF from unproven data retrieval: the public API never exposed the internal response, and no broad internal network scan was performed.
- The permanent fix disabled automatic redirects, strengthened destination validation, and gave the webhook worker its own network controls.
What did the client need tested?
A logistics platform provided partners with an API for creating shipments, retrieving documents, and receiving delivery-status updates. Partners could configure a webhook destination and send a test notification before enabling the integration.
Before expanding access to more integration partners, the organization commissioned an assessment of the API. Particular attention was given to features that caused the platform to make outbound connections to user-supplied addresses.
The scope included two partner test accounts, API documentation, the notification queue, and an agreed internal test endpoint. Carrier systems and real transport orders were excluded.
What did the API penetration test find?
Submitting a private IP address directly as a webhook destination was blocked. At first, the application appeared to enforce the intended boundary between public integration endpoints and internal services.
The tester then configured a controlled public endpoint that returned a redirect. The background worker responsible for delivering notifications followed that redirect without revalidating the destination.
This allowed the worker to send a request to the agreed internal test endpoint.
A unique marker recorded by the internal endpoint, together with the corresponding worker log entry, confirmed the connection.
The application validated the first destination, but not the final destination reached by the HTTP client.
The public API returned only an acknowledgment that the delivery job had been accepted. It did not expose the internal service’s response body. The report therefore distinguished confirmed server-side request forgery from unproven data retrieval.
No broad internal network scan was performed. The assessment did not retrieve infrastructure credentials or claim that the issue provided full server compromise.
Every finding in a Pentestica report comes with its exploitation evidence; our sample penetration test report shows the format.
Why didn’t earlier checks catch the SSRF?
Previous checks validated addresses when partners saved their webhook configuration. They did not examine what happened when the delivery worker received a redirect.
The asynchronous architecture also mattered. The observable effect occurred after the API request had completed, outside its immediate response.
An appropriately configured scanner with out-of-band detection could potentially identify this behavior. The limitation in this scenario was the existing test coverage, not an inherent inability of automated tools to detect SSRF. For where scanning and manual testing each fit, see penetration testing vs vulnerability scanning.
How was the webhook SSRF fixed and retested?
The immediate containment measure restricted the webhook worker’s outbound access to internal networks.
The permanent fix disabled automatic redirects and strengthened destination validation. The worker also received separate network controls rather than inheriting the broader connectivity of the main application backend.
Rejected attempts to reach prohibited destinations were added to security logging.
Retesting took place after six business days and covered the original redirect scenario, IPv4 and IPv6 destinations, and multi-step redirects. Legitimate webhook deliveries were tested alongside the negative cases to confirm that the integration still worked.
Key takeaway
An integration feature does not need to return internal data to create a security exposure. The ability to make trusted infrastructure initiate unauthorized connections can itself cross an important boundary.
Need the same test for your partner API?
This engagement was a grey box test of a partner API, webhook delivery, and asynchronous processing: 6 tester-days, plus 1 tester-day for retesting. A similar pattern, where a check guarded the expected route but not every route, appears in our external penetration testing case study, where direct server access bypassed an SSO gateway.
A standard web application or API test at Pentestica falls in the $2,500–$5,500 range; see how tester-days translate into a fixed price, or request a pentest quote with your endpoint count, roles, and any features that call user-supplied URLs.
Fixed-price quote
Get a fixed-price quote for your pentest
Tell us what to test. You get a written scope, the number of tester-days and a fixed price before any testing starts. No hidden fees.
What happens after you send it
- Tell us what to test Send the number of endpoints and user roles, the spec if you have one, your deadline and any compliance requirement.
- Get a written scope and price We reply by email with scoping questions or a fixed quote in tester-days.
- Test, report, retest Most tests take 1–3 weeks plus a few days for the report. Critical findings are reported during testing. Retesting after fixes is available.
- OSCP, OSCE and CISSP certified testers
- 500+ penetration tests
- Aligned with OWASP WSTG, PTES and NIST SP 800-115
- Executive summary and technical report
The Pentestica penetration testing team: 25 certified senior pentesters (OSCP, OSCE, CISSP) with 10+ years of offensive security operations and 500+ penetration tests behind them. Our testing is aligned with OWASP, PTES and NIST SP 800-115.