API and integration hardening in Magento 2

Part 5 of the Magento 2 security series — implementation-focused. The overview is at /blog/magento2-security.

The API is a front door too

The storefront is not the only way in. REST, GraphQL, and legacy SOAP endpoints serve orders, customers, and inventory to integrators and apps. Each token or integration account is a credential, and a careless one leaks data wholesale. This post hardens the interfaces partners and apps call.

Scope every token to the minimum

Magento issues API access through integration tokens, admin tokens, and customer tokens. The mistake is granting a broad role "because the integration might need it":

• Integration (app) tokens should use a dedicated integration with a role limited to the exact resources the app touches — not Administrator.
• Admin tokens are powerful and short-lived by default; never store them in client-side code or long-lived scripts.
• Customer tokens (for storefront GraphQL) are per-customer and cannot see others' data by design — but the queries they run still need authorization checks server-side.

Review the integration roles in the admin; an integration created years ago for a retired feature is still a valid credential until you revoke it.

Authorize at the resource, not just the route

A route being "authenticated" does not mean it is "authorized." Every resolver and repository method that returns customer or order data must re-check that the caller owns, or is permitted to see, that entity. The breaches that matter are the ones where an authenticated caller walks IDs it should not: order 1001, 1002, 1003… and reads everyone's PII.

Rate limiting and abuse

APIs are scraped and brute-forced constantly:

• Apply rate limits at the edge (WAF / gateway) and, where possible, per-token at the app level. Magento's GraphQL and REST can be throttled via the web server or a module.
• Disable what you do not use. If no integration consumes SOAP, turn it off. A smaller surface is a smaller target.
• Watch for enumeration. Sequential IDs in order or invoice endpoints invite scraping; prefer opaque identifiers and strict ownership checks.

Hardening checklist

• Every integration token has a least-privilege role; retired integrations revoked.
• Resource-level authorization verified on customer/order endpoints (not just route auth).
• Unused API surface (SOAP, legacy REST) disabled.
• Rate limiting in place at edge and/or per-token.
• Token rotation policy defined for long-lived integrations.

What's next

The last post in this series defends the revenue path directly: checkout fraud, payment abuse, and bot traffic — the attacks that cost money in real time.

Next in this series: Checkout fraud, payment abuse, and bot defenses — /blog/magento2-security-checkout-fraud