SEC-4 Tech Due Diligence

Tech Due Diligence SEC-4: Authorization and Access Control

What This Control Requires

The assessor evaluates the authorisation model, including role-based or attribute-based access control implementation, the principle of least privilege, API-level authorisation enforcement, and the prevention of privilege escalation and insecure direct object references.

In Plain Language

Authentication tells you who someone is. Authorisation decides what they are allowed to do. Getting this wrong means users can see data they should not see, perform actions above their role, or access other users' resources entirely.

In a DD review, we examine how your authorisation model works in practice: is it RBAC, ABAC, or something custom? How are roles and permissions defined and managed? Critically, is authorisation enforced at the API and service level, or only in the UI? We check for Insecure Direct Object Reference (IDOR) vulnerabilities, review the admin access model and separation of privileges, and verify whether authorisation decisions are logged for audit purposes.

IDOR vulnerabilities are among the most common and impactful findings in due diligence. These occur when a user can access another user's resources simply by changing an ID in an API call. We specifically test for this by checking whether API endpoints validate that the authenticated user actually has rights to the requested resource, not merely that they are logged in.

How to Implement

Choose an authorisation model that fits your application's complexity. Role-Based Access Control (RBAC) is the right starting point for most products: define roles (admin, manager, member, viewer), map permissions to each role, and enforce those permissions at the application layer. If your requirements are more nuanced, consider Attribute-Based Access Control (ABAC), which evaluates multiple attributes (role, resource ownership, time, location) for each decision.

Enforce authorisation at the API and service level, never just the UI. Hiding a button in the frontend is not security - users can call your APIs directly. Every endpoint that accesses or modifies data must verify the authenticated user holds the right permissions.

Prevent IDOR vulnerabilities by validating resource ownership on every single request. When a user hits /api/documents/123, check not just that they are authenticated but that document 123 actually belongs to their organisation or that they have explicit access. Never rely on ID obscurity for security.

Apply least privilege rigorously: users get the minimum permissions their role requires, admin access is time-limited and separately authenticated, service accounts have narrowly scoped permissions, and permissions are reviewed when roles change.

Log all authorisation decisions, particularly denials and privilege changes. These logs are essential for security monitoring, incident investigation, and compliance auditing.

Test authorisation thoroughly. Write automated tests that verify users cannot access resources or perform actions outside their role. Include authorisation testing in your penetration test scope. Test horizontal privilege escalation (user A accessing user B's data at the same privilege level) as well as vertical escalation (a regular user reaching admin functions).

Maintain an audit trail for permission changes: who granted or revoked access, when, and why. For sensitive permission changes, implement approval workflows.

Evidence Your Auditor Will Request

Authorisation model documentation (roles, permissions, enforcement points)
API-level authorisation enforcement implementation evidence
IDOR prevention measures and testing results
Access control testing as part of penetration test or dedicated assessment
Authorisation audit logging configuration

Common Mistakes

Authorisation enforced only at the UI level; API endpoints lack permission checks
IDOR vulnerabilities present: users can access others' resources by changing IDs
Admin functionality accessible without proper authorisation checks
No audit logging of authorisation decisions or permission changes
Roles are too coarse; all users effectively have the same permissions

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.5.15	Related
SOC 2	CC6.3	Related

Frequently Asked Questions

RBAC or ABAC: which should we implement?

Start with RBAC unless you have a clear need for attribute-based decisions. It is simpler to implement, easier to reason about, and more straightforward to audit. ABAC makes sense when authorisation depends on multiple dynamic attributes beyond role - things like data classification, geographic location, or time of day. In practice, most applications end up with RBAC plus a few ABAC-like extensions for specific edge cases.

How should we handle IDOR prevention?

Build ownership checks into every data access path. Instead of just checking whether a user is authenticated, check whether they own or have explicit access to the specific resource they are requesting. Use framework-level middleware or query scoping to enforce this consistently across all endpoints. Do not rely on UUID obscurity - always validate access explicitly.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment