SAP API Security: Protecting Business Data at the Integration Layer

Why SAP API Security Demands Dedicated Attention

SAP systems have always held the crown jewels of enterprise data: financial records, supply chain transactions, payroll information, customer master data, and intellectual property. But historically, accessing that data required specialized SAP GUI clients, specific transaction codes, and deep knowledge of ABAP or SAP modules. APIs have flattened that access model. With the rise of SAP S/4HANA, SAP BTP, and cloud-extended landscapes, virtually every business function now exposes a programmable interface.

The problem is that many organizations treat SAP APIs the same way they treat any other web API — applying generic API security policies, standard OAuth flows, and traditional web application firewall (WAF) rules. This approach misses the SAP-specific context that attackers exploit. SAP APIs carry unique constructs such as entity sets, navigation properties, function imports, and deep integration with SAP authorizations (PFCG roles, authorization objects, and organizational levels). A generic security tool cannot interpret whether an API call that downloads 10,000 sales orders from the SalesOrderCollection OData endpoint represents a legitimate data export for a monthly report or an insider threat exfiltrating competitive pricing data.

The SAP API Attack Surface in S/4HANA and BTP

To build an effective defense, security teams must understand where SAP APIs live and how they are exposed. The landscape is not monolithic — there are multiple API types and exposure points across modern SAP architectures.

OData and REST APIs in S/4HANA

SAP S/4HANA exposes extensive OData v2 and v4 APIs through the SAP Gateway. These APIs allow CRUD (Create, Read, Update, Delete) operations on virtually every business object — from purchase orders and customer invoices to material master records and production orders. Each OData service has a metadata document that describes all available entities, properties, and associations. Attackers frequently use this metadata to map the attack surface, identifying which business data is accessible and what operations can be performed.

Common risks include:

• Over-exposed entities: Services that expose more data than the consuming application requires, allowing an attacker who compromises a single API key to access unintended data sets
• Missing or weak query parameter validation: OData supports $filter, $orderby, $top, $skip, and $expand parameters that, when unvalidated, can be used to extract large data sets or bypass authorization checks
• Insecure navigation property access: The $expand parameter can traverse relationships between entities, potentially exposing data beyond what a user or service account is authorized to see
• Lack of throttling: APIs without rate limiting or data volume controls enable bulk data extraction attacks

SOAP and RFC Interfaces

While OData dominates modern S/4HANA integration, SOAP web services and RFCs remain critical for legacy and hybrid landscapes. SOAP services use WSDL documents and operate over HTTP/S, while RFCs use the SAP proprietary Remote Function Call protocol. Both carry enterprise data and often have weaker security controls than newer API types.

Key risks include:

• Unsecured RFC destinations: RFC connections configured with hardcoded credentials, missing encryption, or overly permissive authorization profiles
• SOAP message-level attacks: XML External Entity (XXE) injection, SOAP action spoofing, and lack of WS-Security headers

SOAP WSDL enumeration allowing attackers to discover available functions and their parameters

SAP BTP APIs and Custom Microservices

SAP BTP extends the attack surface significantly. Organizations build cloud-native extensions, deploy custom CAP (Cloud Application Programming Model) services, and integrate third-party APIs. These services authenticate via OAuth 2.0, XSUAA (SAP's UAA service), or API keys. The complexity of managing service-to-service authentication, scopes, and token exchange creates opportunities for privilege escalation and lateral movement.

Common BTP-specific risks include:

• Over-provisioned OAuth scopes: Extension applications requesting broader scopes than needed, allowing an attacker who compromises the application to access unrelated BTP resources
• Insecure OAuth flows: Use of implicit grant type, missing PKCE (Proof Key for Code Exchange), or weak client secret management
• Unmonitored service-to-service calls: Internal API calls between BTP services that bypass typical monitoring because they are not logged at the application gateway

Threat Scenarios for SAP APIs

Understanding how real attacks exploit SAP APIs helps security teams prioritize controls. The following scenarios represent the most common and damaging SAP API-related threats observed in enterprise environments.

Bulk Data Exfiltration via OData

An attacker who gains valid API credentials — either through phishing, credential theft, or compromising a connected application — can craft OData queries that extract massive volumes of data. For example, a single HTTP GET request to /sap/opu/odata/sap/ZHR_EMPLOYEE_SRV/EmployeeSet with no filter criteria returns the entire employee master data table. If the API is unthrottled, the attacker can dump all employee records — including salary data, personal identification numbers, and bank account details — in seconds.

The risk increases when attackers exploit $skip and $top pagination parameters to iterate through large data sets, or use $expand to pull related data such as organizational assignments and cost center allocations in a single request. A properly secured SAP environment would flag this behavior as anomalous, but many organizations lack SAP-aware monitoring to detect it.

Authorization Bypass Through Entity Manipulation

SAP OData services enforce authorization through the PFCG role model, mapping user roles to allowed operations on specific entities. However, implementation flaws can allow attackers to bypass these controls. For example, modifying a URL entity set name, manipulating navigation property paths, or sending requests with unexpected HTTP methods can sometimes bypass SAP Gateway's authorization checks.

In one documented real-world scenario, a financial analyst modified a GET request to a purchase order API, changing the entity set name slightly to access a related but unauthorized data set. The API gateway had not explicitly restricted the navigation property path, allowing lateral data access. This type of attack is extremely difficult for a generic API security tool to detect because the request appears structurally valid — only SAP-contextual authorization analysis can identify the violation.

OAuth Scope Escalation in BTP

SAP BTP applications use JSON Web Tokens (JWTs) signed by XSUAA. The token contains the OAuth scopes granted to the requesting service or user. If an organization has not carefully scoped permissions, an attacker who compromises one microservice can use its token to call APIs from other services with elevated privileges. This lateral movement risk is especially high in environments where scopes are defined broadly (e.g., "scope": "read_all" instead of "scope": "read_financial_data").

Detection requires real-time token validation and scope verification at every API boundary — not just at the ingress gateway. Without this, an attacker can pivot across BTP services undetected, accessing progressively more sensitive data and operations.

Foundational Controls for SAP API Security

Building a strong SAP API security posture starts with foundational controls that every organization should implement, regardless of the specific security tooling in use.

API Gateway Hardening

Whether using SAP API Management, SAP Cloud Platform API Management, or a third-party gateway (e.g., Kong, Apigee, Azure API Management), the gateway is the first line of defense. Best practices include:

• Enforce TLS 1.2 or higher for all API endpoints — no plaintext HTTP
• Implement strict input validation for all OData query parameters ($filter, $expand, $select, $skip, $top)
• Block unsupported HTTP methods (e.g., PUT or DELETE on read-only services)
• Apply rate limiting and data volume caps per client ID or user
• Enable detailed request and response logging for all API calls, including query parameters, response sizes, and response times

Identity and Access Governance for APIs

APIs do not authenticate themselves — they authenticate the calling identity, whether that is a human user via a Fiori app, a service account in a middleware system, or a BTP microservice. Identity governance must extend to API-level access:

• Use OAuth 2.0 with the authorization code grant type and PKCE for user-facing applications
• Use the client credentials grant type for service-to-service communication with strictly scoped tokens
• Map OAuth scopes to SAP authorization objects at the API management layer, not just at the application level
• Regularly audit token usage, refresh token rotations, and expired credentials
• Revoke API credentials immediately when a service account or user is deprovisioned

SAP Gateway and IWBEP Hardening

On the SAP backend, the Gateway and IWBEP (ABAP Gateway Framework) runtime must be hardened:

• Disable metadata exposure for services that do not require it — or at minimum, restrict metadata access to authenticated and authorized identities
• Use the SAP Gateway authorization checks (SERVICE_AUTH, SCOPE_AUTH, ACT_AUTH) correctly, avoiding common misconfigurations where checks are set to UNCHECKED
• Implement custom GET_ENTITY and GET_ENTITYSET method implementations that validate authorization at the data layer, not just at the service layer
• Apply S_DEVELOP authorization restrictions for ABAP developers who might modify service implementations

Monitoring SAP API Traffic for Anomalous Behavior

Foundational controls reduce the attack surface, but they cannot prevent all API-based attacks — especially those using legitimate credentials. Continuous monitoring of SAP API traffic is essential to detect anomalous behavior that signals an active threat.

What to Monitor

SAP API monitoring must go beyond basic metrics like request count and error rates. Security teams should instrument monitoring for the following indicators:

Correlating API Events with SAP Transactional Logs

API monitoring becomes significantly more powerful when correlated with traditional SAP audit logs. A high-volume OData download may be benign when executed by a batch job with a legitimate service account, but malicious when originating from a user account that has never accessed that API before. CyberSilo SAP Guardian performs this correlation natively, linking API events from SAP Gateway, BTP Cloud Foundry logs, and XSUAA audit trails with SAP security audit log entries and authorization change documents.

This correlation enables detection of complex attack patterns such as:

• A user who recently received an authorization change (e.g., a new role assignment) immediately executing a bulk API download — indicating potential privilege escalation abuse
• An RFC destination being created or modified, followed by API calls executing via that destination — indicating a potential backdoor or supply chain compromise
• A service account performing actions that deviate from its established behavioral baseline — indicating possible credential theft or script compromise

Implementing an SAP API Security Monitoring Framework

Organizations ready to move beyond foundational controls can implement a comprehensive SAP API security monitoring framework. The following phased approach is suitable for S/4HANA and BTP deployments.

This framework works best when enabled by purpose-built tooling that understands SAP API semantics. CyberSilo SAP Guardian was designed specifically for this use case, providing out-of-the-box detection rules for SAP OData, SOAP, RFC, and BTP API traffic, with native correlation to SAP authorization events and change logs.

Comparing SAP API Security Approaches

Organizations evaluating how to secure their SAP APIs typically consider several approaches. The following comparison highlights the strengths and limitations of each.

The Role of Behavioral Analytics in SAP API Security

Static detection rules — such as blocking known IP ranges or denying specific HTTP methods — are necessary but insufficient. Advanced attackers use legitimate credentials, access APIs from expected IP ranges, and execute actions that appear normal at a surface level. Behavioral analytics provides the next layer of defense by learning what "normal" looks like for each SAP API consumer and detecting subtle deviations.

User and Service Account Baselining

Each API consumer — whether a human user authenticated via SAML or a BTP service account using a JWT token — has a behavioral fingerprint. This includes:

• Access patterns: Which APIs they call, at what frequency, during which hours
• Data volume: Typical response payload sizes and number of records returned
• Query complexity: Use of filters, expands, and custom query parameters
• Temporal patterns: Time of day, day of week, and seasonal trends

CyberSilo SAP Guardian builds these baselines automatically over a configurable observation period (typically 14–30 days). Once established, the system flags any significant deviation. For example, a normally passive user account that calls a financial OData service 500 times in a single hour would trigger a high-severity alert — even though the credentials are valid and the requests are structurally correctly formed.

Sequence Anomaly Detection

Many SAP API attacks follow a predictable sequence: reconnaissance (listing services), enumeration (querying metadata), and exploitation (extracting data). Behavioral models can detect this sequence even when each individual step appears benign. A user who queries the SAP Gateway metadata endpoint, then calls three separate OData services with $expand parameters, then initiates a bulk download — all within five minutes — represents a high-risk sequence that would be invisible to a stateless API gateway.

Integration with Existing SAP Security Tooling

An SAP API security solution should complement, not replace, existing investments in SAP GRC, SAP Security Audit Log, and SAP Cloud Identity. The key is creating a unified security data plane where API events, authorization changes, and user context are correlated automatically.

For example, when SAP GRC Access Control detects a SoD (Segregation of Duties) violation in a role change — say, a user gaining both "create purchase orders" and "approve invoices" authorizations — the monitoring system should immediately flag that user's API activity for increased scrutiny. If that user subsequently executes API calls that combine both functions, the system triggers a containment alert. This cross-domain correlation is exactly what CyberSilo SAP Guardian was designed to deliver, bridging the gap between static authorization governance and real-time API monitoring.

Similarly, integration with the SAP Cloud Identity Provisioning service enables the monitoring system to understand user lifecycle events — new hires, role changes, departures — and adjust baselines or detection sensitivity accordingly. An API call from an employee who left the company two days ago should trigger immediate account suspension, even if the token has not yet expired.

Compliance Implications for SAP APIs

For organizations subject to SOX, PCI DSS, ISO 27001, or GDPR, SAP API security is not optional — it is a documented control requirement. Auditors increasingly ask specific questions about API access controls:

• How is API access authenticated and authorized in S/4HANA and BTP?
• Is there a complete inventory of all API endpoints that process sensitive data?
• Are logs maintained for all API calls that access financial or personal data?
• Is there real-time monitoring for unauthorized or anomalous API activity?
• How are service accounts and technical users managed for API access?
• Are there documented procedures for revoking API access when users leave or change roles?

Organizations that cannot answer these questions with documented evidence face compliance findings. The SAP API security framework described in this article directly addresses each of these auditor requirements. Implementing a monitoring solution like CyberSilo SAP Guardian demonstrates due diligence and provides the audit trail that compliance teams and external auditors demand.

Building an SAP API Security Roadmap

For organizations at the beginning of their SAP API security journey, a phased roadmap helps manage complexity and demonstrate progress. The following recommendation is based on field experience across multiple enterprise SAP deployments:

Phase 1 (Weeks 1–4): Complete API inventory and classification. Enable SAP Gateway and BTP audit logging. Configure basic monitoring for known attack signatures using existing SIEM or security tools.

Phase 2 (Weeks 5–12): Deploy purpose-built SAP API monitoring with behavioral analytics. Establish baselines for all critical APIs. Create incident response playbooks for API-related alerts. Begin integrating API events with SAP authorization change data.

Phase 3 (Months 4–6): Automate response actions for high-confidence alerts (token revocation, account suspension). Extend monitoring to RFC interfaces and legacy SOAP services. Implement regular API security reviews as part of the change management process.

Phase 4 (Ongoing): Continuously refine detection models based on new threat intelligence. Expand coverage to new APIs as they are deployed. Conduct quarterly penetration testing of SAP API endpoints. Report API security metrics to the CISO and compliance committees.

Throughout this roadmap, organizations should leverage the top 10 SIEM tools evaluation as a resource for selecting a SIEM platform that integrates well with SAP monitoring. For organizations concerned about the operational cost of monitoring, the SIEM tool cost guide provides budgeting context for the broader security operations ecosystem in which SAP API monitoring operates.