Skip to content
Exploit Labs
SAP · S/4HANA · RFC · BTP

SAP penetration testing: where authorizations turn into money.

SAP risk is rarely a missing patch. It is a business user with one authorization too many, an openly registered RFC program, or an OData service with no authorization check. We test both - technical layer and process - and prove which path really leads to a posting, a payment or a data leak.

Production-aware·Assumed breach optional·Retest included
Scope

Six test areas, clearly bounded.

Authorizations & roles

Critical profiles, wide object authorizations, debug and change rights, technical users, segregation of duties where it can be bypassed technically.

SAProuter & RFC gateway

Routing tables, gateway and message-server hardening, external program registration, RFC trust between systems and the path from QA into production.

Web & OData exposure

Fiori launchpad, ICF services, OData endpoints, authentication and session handling, authorization enforcement at service level.

Custom ABAP code

Missing AUTHORITY-CHECKs, dynamic calls, file and directory access, unsafe RFC wrappers - reviewed where code or access is provided.

Business-process abuse

Payment, procurement and master-data processes: which chain can be assembled from legitimate rights in a way that creates real financial damage?

BTP & integration

Subaccount and role model, destinations, cloud connector, principal propagation, published APIs and their authentication.

We do not claim to cover every SAP component. What we test is named before the quote - and so is what we do not test.

Delivery & safety

Testing without risking operations.

  • Kick-off with SAP Basis, security and the business: system boundaries, clients, windows, contacts, escalation path.
  • Read-only analysis and exposure checks can run in production; anything that changes state runs in a production-like QA system.
  • Documented stop conditions, mandatory approval for potentially disruptive techniques, a phone abort path during test windows.
  • Report with reproducible chains, affected objects and transactions, prioritised remediation and effort estimates.
  • Retest of remediated findings; evidence stored encrypted and deleted after the agreed retention period, with written confirmation.
FAQ

Common questions about SAP pentests

+What does an SAP penetration test cover?

The technical attack surface of your SAP landscape plus business-logic abuse: authorization and role design, RFC gateway and SAProuter, exposed web and OData interfaces, integration paths, and custom ABAP code where in scope. The measure is what an attacker can actually achieve with a valid business-user account or from the outside.

+Do you test production or a test system?

Preferably in a production-like QA system for anything that can change data or create load spikes, and in production only for read-only checks and exposure analysis - each in agreed windows with documented stop conditions and a named SAP Basis contact.

+Which authorization topics do you examine?

Critical profiles and overly wide object authorizations, segregation of duties where it is technically exploitable, debug and change rights, transport paths, RFC trust relationships between systems, and service or communication users holding more rights than needed.

+Are BTP and cloud integration in scope?

On request yes: BTP subaccount and role model, destinations and cloud connector, principal propagation, API exposure and authentication of published services. During scoping we state clearly what is tested and what remains the operator's responsibility.

+Do you review custom ABAP code?

We review custom developments where source or access is provided - typical patterns are missing authority checks, injection through dynamic calls, directory traversal in file interfaces and unsafe RFC wrappers. Without code access the review stays behaviour-based.

+What do you need to quote?

A system list with roles (PRD/QA/DEV), the components in use (ECC or S/4HANA, Fiori, Gateway, PI/PO or Integration Suite, BTP), the number of exposed interfaces, whether an authorization review is wanted, and whether a business-user account will be provided for assumed-breach testing.

Confidential

Request scoping - confidentially.

Describe in a few sentences what needs testing. We come back with concrete questions, the right type of exercise and an effort range - before you commit to anything.

Not ready to talk yet? The Scope Check returns exercise type, tester-days and a budget range in two minutes - no email gate.