ABAP Development Tools (ADT): Development and Execution Permissions

Updated on Nov 7, 2026 adt authorization code execution http source disclosure

Description

ABAP Development Tools (ADT) exposes development resources through the AS ABAP HTTP(S) service tree /sap/bc/adt. Besides the source-reading capabilities used during an ABAP code review, an authenticated user may be able to create or change development objects, activate them, and execute programs. An exposed development interface therefore belongs in the authorization assessment even when SAP GUI and binary RFC access are restricted.

Reachability, source access, object modification, activation, and execution are separate capabilities. A discovery response or readable source does not establish that the user can install or run code. Assess each capability against the user’s intended role, selected client, system change settings, and permitted object/package scope. This page concerns classic AS ABAP; ABAP Cloud environments have different development and runtime restrictions.

The authorization review must include both access to ADT resources (S_ADT_RES) and the underlying development permissions (S_DEVELOP). SAP documents S_ADT_RES as a URI-based access check; allowing a resource does not establish authorization for every operation behind it. Confirm the actual checks on the assessed release instead of treating a broad resource grant as proof of execution access.

Risk

An account with excessive development rights can turn an ordinary authenticated HTTP(S) session into unauthorized application-code changes or ABAP execution. Read-only access can expose business logic and embedded credentials. Modification and activation can alter application behavior, while executable ABAP may reach application-server files, database data, RFC destinations, or outbound services.

Runtime access depends on kernel-enforced checks, application checks implemented by the code, and the privileges of the underlying connections. Do not assume ordinary transaction or table-browser restrictions constrain developer-created ABAP: direct ABAP SQL does not automatically enforce the business user’s table-browser authorizations. Filesystem operations, CDS access controls, called APIs, and database connections have different enforcement mechanisms. Development rights therefore need assessment as a potential route around application-level access boundaries, even when the account’s normal business transactions are restricted.

These consequences require separate evidence. ABAP execution is not automatically OS command execution, unrestricted database access, or a filesystem authorization bypass. See Accessing filesystem (read), Critical RFC-enabled Function Modules, and Critical Authorizations and Segregation of Duties for the corresponding access boundaries.

Options

Service and identity review - identify the active ADT services, authenticated user, selected client, and intended development scope. Use ADT discovery and the supported client for that release to identify available resources; distinguish authentication failures from resource or object authorization denials.
Source access - check whether the assessed user can inspect objects outside their assigned scope. Record the object/package boundary and compare it with the intended role. Follow the existing ABAP code-review process for source inspection.
Capability assessment - use one approved, uniquely named test object to assess creation, modification, activation, and execution independently. A harmless program that prints a fixed marker is sufficient to demonstrate execution; saving source or receiving a successful activation response alone is not execution evidence.
Runtime access assessment - where separately included in scope, use designated test files, synthetic database data, and approved destinations to establish what the executing program can access. Record successful and denied operations without extrapolating from one resource to unrestricted access.
Authorization review - compare S_ADT_RES resource scope and S_DEVELOP object/package/activity restrictions with observed behavior. Include applicable program-execution and downstream resource checks. Use an authorization trace where available to resolve an ambiguous denial rather than guessing which authorization object caused it.
Change-control review - examine the system change option, software-component and namespace restrictions, and relevant client settings alongside development authorizations. Check whether local objects or development packages are consistent with the organization’s production policy. Object creation without a transport request does not by itself establish a change-control bypass.
Cleanup - release test-object locks and remove approved test objects and generated outputs. Retain the object names and cleanup result in the engagement record so later repository review can distinguish assessment activity from an unexplained change.

Note
Report the highest demonstrated capability: source read, repository modification, activation, ABAP execution, or a specific downstream access. A file read performed by authenticated ABAP is evidence of that account’s effective access, not proof of an unrelated pre-authentication vulnerability.

Mitigation

Enable and expose ADT services only where required; check operational dependencies before deactivating services in production. Restrict development access to intended users and trusted networks, require HTTPS with certificate validation, and configure authentication according to the organization’s identity policy.
Scope ADT resource grants and development permissions to the required objects, packages, and activities. Review effective user permissions across all assigned roles.
Restrict development and activation in production through appropriate system change options, software-component/namespace restrictions, relevant client settings, and user authorizations. These controls complement each other. Use monitored, time-limited emergency access where an exception is required.
Review runtime access separately from development permissions, including kernel-enforced filesystem checks, called APIs, database-connection privileges, RFC destinations, and outbound connectivity. Business-user restrictions alone are not a sufficient boundary for an account that can introduce executable ABAP.
Remove embedded secrets from source and review developer access to sensitive repository objects.

Detection and Monitoring

ICM/Web Dispatcher access logs: enable logging for the relevant ADT paths and verify that the configured format and retention capture the request method, path, time, response status, and available source and identity information. Confirm coverage with a benign test. Authentication mode and proxy placement affect attribution; a Web Dispatcher request does not necessarily identify the effective ABAP user. Avoid recording credentials, session tokens, or source bodies unnecessarily.
Security Audit Log: configure the appropriate client/user filters and available logon, report-start, and security-relevant change events. Verify which events the assessed ADT execution path actually generates rather than assuming every HTTP operation or source change has an audit event. See Logging and Detection Surface for general configuration and coverage limits.
Repository/version and transport records: investigate unexpected object creation, source changes, and activation, especially in production or outside the user’s assigned package scope. Transport records alone do not cover all local development activity; correlate them with available repository records and HTTP activity.
Development-role changes: monitor grants and changes to ADT resource and development permissions, and correlate newly acquired capabilities with subsequent development activity. See Critical Authorizations and Privilege Hunting for effective-permission review and authorization-change records.
Correlate available HTTP, audit, repository, activation, execution, and downstream-access records. Authorization traces can explain individual checks during an assessment but are diagnostic tools, not a substitute for continuous monitoring. Validate coverage and retention on the assessed release; an HTTP success status alone does not prove the intended operation completed.
Treat development activity by display-only or business accounts, unexpected source networks, and activity outside approved change windows as signals requiring context. Discovery requests and CSRF-token fetches are normal client behavior; none of these signals alone establishes malicious activity.