Access control
The rules and mechanisms that decide who may use which systems, data or rooms, and in what way.
Draft - this entry has not been reviewed yet.
Formal
The enforcement of a policy on every request to use a resource, combining authentication (who is asking) with authorization (what they may do) to allow or refuse it. It covers digital resources and physical ones such as doors and server rooms.
In plain English
Like the whole door system of an office building - the key-card readers, the list of who may enter which floor, and the lock that actually holds the door shut.
In practice
At a Danish regional hospital, nurses can open records only for patients on their own ward; the patient record system checks every lookup against that rule and logs each refused attempt.
Why it matters
It is where the confidentiality and integrity of data are actually enforced; without it, every security policy is just words on paper.
How to put it into practice
The usual steps, in order. Adapt them to your organisation.
- For each system, have the system owner write down the access rules in plain words - which roles or attributes may read, change or delete which data - and get them approved before anything is built.
- Choose the model that fits the rules, such as roles for simple job-based access and attributes or relationships for rules like "only patients on my own ward", and write the choice into the design.
- Put the check in one central enforcement point on the server, such as a middleware, API gateway or policy engine, instead of scattering if-statements through the code or relying on hiding buttons in the user interface.
- Deny by default, so any request, page, file or API call without an explicit rule is refused, and make the system refuse access if the policy engine or directory cannot be reached.
- Check the rights on every request and on every single record, not only at login, so a user cannot open another person's case by changing an ID in the URL.
- Log both refused and allowed access to sensitive data with user, object and time, and alert on repeated refusals from the same account.
- Write automated tests for the access rules, including attempts to reach other users' records and admin functions, and run them in the build pipeline on every change.
- Test access control in every penetration test or code review, and review the rules with the system owner at least yearly and whenever the system changes.
Common pitfalls
- Hiding a menu item or button in the user interface but leaving the API behind it open to anyone who calls it directly.
- Checking that a user is logged in without checking that the record they ask for is one they may see, which gives insecure direct object references.
- Failing open, so everyone is let in when the policy engine, directory or permission lookup times out.
Good guides
- Authorization Cheat Sheet(opens in a new tab) · OWASP
- A01 Broken Access Control - OWASP Top 10:2025(opens in a new tab) · OWASP
- NIST SP 800-162 - Guide to Attribute Based Access Control (ABAC) Definition and Considerations(opens in a new tab) · NIST
- Rettighedsstyring(opens in a new tab) · Datatilsynet (in Danish)
Technical deep dive
The theoretical baseline is Lampson's access matrix (1971): subjects as rows, objects as columns, and a set of rights in each cell. Real systems never store the matrix; they slice it either by column, giving access control lists attached to objects (Unix mode bits, POSIX ACLs, NTFS DACLs, S3 bucket policies), or by row, giving capabilities held by subjects (file descriptors, object-capability references, bearer tokens). The 1972 Anderson report added the reference monitor concept: the enforcing component must be invoked on every access (complete mediation), be tamper-proof, and be small enough to verify. Those three properties are still the right yardstick for any enforcement point.
Policy models sit on top. Discretionary access control (DAC) lets the owner of an object grant rights, as with chmod. Mandatory access control (MAC) enforces system-wide labels the owner cannot override; Bell-LaPadula ("no read up, no write down") protects confidentiality and Biba protects integrity, and SELinux and AppArmor bring MAC to Linux. Role-based access control (ANSI INCITS 359-2004) routes permissions through roles, attribute-based access control (NIST SP 800-162) evaluates rules over subject, object, action and environment attributes, and relationship-based access control, popularised by Google's Zanzibar paper (2019), derives rights from a graph of relations such as owner, member and parent folder. Production systems usually combine several.
Architecturally, the XACML vocabulary is standard: a policy enforcement point (PEP) intercepts the request, a policy decision point (PDP) evaluates it, a policy information point (PIP) supplies attributes, and a policy administration point (PAP) manages rules. NIST SP 800-207 reuses the PEP/PDP split for Zero Trust. Externalised engines such as Open Policy Agent (Rego) or Cedar keep policy out of application code. Sound defaults are deny-by-default, enforcement on the server for every request and every object, fail-closed when the PDP is unreachable, and logging of both allow and deny decisions.
Failures are common: Broken Access Control is A01 in both OWASP Top 10:2021 and Top 10:2025, covering insecure direct object references, missing function-level checks, forced browsing, tampered tokens and, from 2025, SSRF. The confused deputy problem (Hardy, 1988) shows how a privileged program can be tricked into spending its authority on behalf of a caller; time-of-check-to-time-of-use gaps and cached decisions that survive revocation are other classic faults. Access control is the per-request mechanism; access management is the lifecycle of granting, recertifying and removing rights. ISO/IEC 27001:2022 covers both in Annex A 5.15-5.18, with 7.2 for physical entry and 8.3 for information access restriction.
What to learn first
Everything this builds on, foundations first.
- Digital identity
- →Credential
- →Authentication
- →Access control
Relationships
- A kind of
- Security control
- Consists of
- AuthorizationPermission
- Requires
- Authentication
- Implemented by
- Access management
- Don't confuse with
- Access management
Sources & further reading
Standards & official texts
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Mentioned in
Check yourself
Loading…