crAPI — API Security Investigation

Case summary

A crAPI assessment with 9 documented findings, from critical BOLA and JWT alg:none to a low-severity data exposure, each with a proof of concept.

Overview

The sections below are a concise case-file overview. The detailed assessment report is kept separate so the case page remains readable while the complete evidence and findings remain available to readers who want them.

Context

crAPI is an intentionally vulnerable application designed for practicing modern API security. I used it as a controlled environment to move beyond individual vulnerability exercises and think about an API as a system of related trust boundaries.

Objective

The objective was to understand how API behavior changes when requests, identities, and object references are manipulated, and to build a repeatable workflow for investigating those behaviors.

Scope

The assessment was limited to the locally deployed crAPI environment. No production systems or third-party targets were involved.

Methodology

Reconnaissance

I began by identifying the application’s exposed functionality and the API requests generated during normal use. Burp Suite and Postman were useful for making the request structure visible rather than relying only on the browser interface.

Investigation

I compared normal requests with deliberately modified requests, paying attention to authentication state, identifiers, parameters, response codes, and the data returned by the API.

Validation

Potential weaknesses were treated as hypotheses first. I focused on reproducing behavior consistently and recording the evidence needed to explain the underlying trust decision.

Findings

The full report documents 9 findings, summarized here as reported. Every one has a request/response proof of concept in the PDF.

Detection Angle

The same request-level evidence used during an assessment can support defensive monitoring. Authentication events, unusual object-access patterns, repeated authorization failures, and anomalous request sequences can provide useful signals when correlated with application and API gateway logs.

Remediation

The defensive response depends on the confirmed weakness, but the general principle is to enforce security decisions server-side, validate authorization at the point of resource access, minimize unnecessary data exposure, and log security-relevant events with enough context to investigate them.

What I Learned

The most useful lesson was to slow down. Understanding the normal request flow first makes unusual behavior much easier to recognize and explain.

What I’d Do Differently

I would capture a cleaner request inventory at the beginning and maintain a test matrix for authentication, authorization, input handling, and object-level access throughout the assessment.