Security audit for REST and GraphQL APIs

Discovery

Mass assignment in POST /api/v3/orders

The endpoint accepted the full Order entity payload on creation, without filtering sensitive properties. Sending { "items": [...], "total": 0.01, "status": "PAID" } the backend persisted the order with manipulated total and PAID status without verifying payment. The frontend never sent those fields but the backend accepted them without validating ownership or property whitelist.

Severity

CVSS 4.0 = 9.0 (Critical)

AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N. Network, low complexity, requires an authenticated account (any registered user). Impact: high integrity (orders created without payment, no fraud detected in billing systems because the legitimate flow is skipped). Confidentiality and availability unaffected. Business impact higher than CVSS suggests: any customer could order products without paying.

Evidence

Proof without real abuse

Demonstration with a test account created for the project, in staging with identical configuration to production. Capture of request/response, backend log showing acceptance of the payload, screenshot of the record in the database. No production tests were run to avoid inconsistencies in real billing.

Remediation

Mitigation + permanent patch

Immediate (6 hours): API Gateway rule dropping total and status properties from incoming payload. Medium-term (1 week): code patch using input DTO limited to customer fields (items, billingAddress, shippingAddress); the rest is calculated server-side. Long-term: audit of every POST/PUT/PATCH endpoint looking for the same pattern. Five more endpoints with mass assignment were found.

Strong fit

When it makes sense

• Your API is the central piece of the product (B2B SaaS, fintech, healthtech, marketplace)
• Public API consumed by third parties or by your own mobile app
• An API v2 goes to production or the authentication model changes
• Multi-tenant: validate isolation between customers
• Auditor requires evidence: PCI DSS, DORA, NIS2, ISO 27001, enterprise contract
• Migration to microservices or move to GraphQL
• Post-incident: there was a leak, abuse or impersonation via API

Weaker fit

When it is not the first move

• API in prototype phase with no real traffic: let it mature first
• If your product is essentially web and the API is just a minor internal BFF: web audit already covers it
• Problem comes from development process (secrets in repos, no code review): start with source code audit
• Need continuous monitoring, not point-in-time: combine with attack surface management
• After an active incident, first incident response; audit later

1. Technical walkthrough (1-2 days)

Session with the developer maintaining the API. We review OpenAPI spec or Postman collection if available; if not, we map endpoints in session. We agree scope, window, source IPs, communication plan with IT/SOC, and test account model (especially important in multi-tenant SaaS to verify isolation).

2. Manual + automated audit (60-80% of time)

Burp Suite Pro, Postman/Bruno, custom scripts. For GraphQL we add InQL and graphw00f. Exhaustive tests on authentication (JWT manipulation, OAuth flows, refresh), authorisation (BOLA/BFLA/BOPLA), rate limiting, exposed business logic. Critical findings reported instantly with immediate mitigation rule proposed.

3. Documentation and verification

Each finding with request/response, CVSS 4.0, business impact, proof-of-concept, code remediation recommendation + immediate mitigation rule for WAF/API Gateway. Double verification to avoid false positives in the final report.

4. Closing and retesting

90-minute session with API development and operations. Discussion of findings, remediation plan, real priority. If contracted, retesting at 4-8 weeks certifying corrections work and issuing verification letter suitable for external auditor.

B2B SaaS and platforms

Heavy focus on multi-tenant isolation, OAuth, BOLA/BFLA/BOPLA. Compatible with SOC 2 if applicable. Almost always also requires evidence to respond to enterprise customer security questionnaires.

Fintech and financial entities

DORA (art. 24-27) compliance on resilience testing. PCI DSS 6.4.3 and 11.4.3 if it touches CDE. Focus on payment flows, fraud prevention, transfer race conditions, strong customer authentication (SCA).

Healthtech and healthcare platforms

Focus on special data exposure (GDPR art. 9), HL7/FHIR integrations, medical role authorisation, access auditing. If ENS High applies (essential operators): op.exp.5.

Public sector and digital services

ENS compliance by system categorisation. National e-ID identity, digital certificates, accessibility where applicable. Citizen-facing platforms need privacy and special data focus.

Marketplace or third-party platforms

API consumed by external partners: focus on service-to-service authentication, minimum OAuth scope, per-consumer rate limiting, anomalous usage monitoring. Fits NIS2 art. 21 (ICT risk management) and third parties.

Mobile applications with own backend

Focus on certificate pinning, traffic encryption, secure token storage on client, secret obfuscation in bundles, server-side validation of everything the client sends.

«Our API is internal, we do not audit it»

The argument works only as long as no one is inside your network. The day an attacker enters through a supply chain, a compromised employee or a vulnerable microservice, your internal APIs are their best pivot. NIS2 and DORA capture this: they ask for controls on ALL critical ICT services.

«We already run monthly DAST scans on the API»

Good. But DAST does not detect BOLA in your data model, nor BOPLA because it does not know which fields are protected, nor business logic abuse because it does not understand what a legitimate order looks like. You cover the wide surface well; we cover what is hidden to the tool.

«We have automated tests in CI, we already cover security»

CI tests validate functionality under expected cases. An attacker does not play under expected cases: they try combinations the developer did not consider. A CI test will never find a BOLA because the team that wrote the test knows the app filters by tenant. The attacker tests what happens if it does NOT.

«It is expensive. Is it worth it for a medium API?»

A multi-tenant SaaS API compromised with BOLA leaks personal data: notification to the supervisor (potential 4% of revenue fine), loss of enterprise customers for contractual breach, DFIR (€15-50k), urgent remediation (€40-80k), reputation. A €12-20k audit that avoids this is the most profitable investment of the year.

«Our API is simple REST, we do not need a dedicated audit»

The most critical modern findings are BOLA, BFLA and BOPLA. They appear in simple REST the same as in complex GraphQL. If your API handles money, personal data or business decisions, you deserve the dedicated audit. If it is just internal BFF for a small web, a chapter within a web audit covers it.

«We have no OpenAPI spec, can you still audit?»

Yes. We map endpoints in the initial technical walkthrough, with developer or Postman collection. Takes 1-2 hours more, does not change the result. In fact, in audits without spec we sometimes find forgotten endpoints the security team did not know existed (API9 — Improper Inventory).