Access Control List (ACL)

Overview

Context and purpose

The control exists to ensure that only appropriately identified and authorized principals can access resources or approve actions at the required level of assurance. An ACL expresses permissions, while discretionary access control describes a governance model in which an authorized owner may grant or remove those permissions. It should be interpreted alongside Discretionary Access Control (DAC) because the concepts can affect the same decision without representing the same control, event, or risk. The workflow establishes a trusted identity or service principal, binds authenticators, evaluates context, applies policy, and records the resulting access decision. Authorization must be enforced by the server or resource boundary on every relevant request and should not depend on hidden interface elements or untrusted client claims. In this context, rules should use least privilege, explicit scope, stable identities, controlled inheritance, change approval, periodic review, conflict handling, and logging of both decisions and denied attempts.

How it works

An ACL is a set of permissions specifying which identities may perform actions on particular resources. In payment services, it should cover individual merchant objects as well as broad endpoint privileges.

Practical checks and failure points

Enforce permissions on the server for every object ID, audit policy changes and review least-privilege access regularly.

Related concepts

Account Takeover Fraud · Audit Trail

Further reading

• api-security.owasp.org official reference