A security policy baseline for exposing SAP OData APIs

The problem

An S/4HANA OData service is exposed to a partner portal or mobile app. Without policies in front of it, one misbehaving client can overload the backend, error responses can leak internal details, and there is no record of who called what.

The baseline

• Authentication: verify an API key for identification, and OAuth 2.0 for anything that reads or changes business data.
• Spike arrest: smooth sudden bursts so the backend never sees a flood.
• Quota: cap calls per application per day or month, matched to the agreed usage.
• Header hygiene: remove backend headers and cookies before the response leaves the proxy.
• Error handling: replace backend error pages with a clean, consistent error format.
• Analytics: keep usage data per application for capacity planning and audits.

Example policies

A spike arrest that allows roughly 30 calls per minute:

<SpikeArrest async="true" continueOnError="false" enabled="true"
    xmlns="http://www.sap.com/apimgmt">
  <Rate>30pm</Rate>
</SpikeArrest>

A daily quota per application, identified by its API key:

<Quota async="false" continueOnError="false" enabled="true" type="calendar"
    xmlns="http://www.sap.com/apimgmt">
  <Identifier ref="request.queryparam.apikey"/>
  <Allow count="5000"/>
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <StartTime>2026-01-01 00:00:00</StartTime>
</Quota>

Adjust the identifier to where your clients actually send the key, for example a header instead of a query parameter.

Result

Every SAP API starts from the same secure baseline, partners get predictable limits, and the backend is protected from accidental overload.