Åtkomstkontroll styr vad autentiserade användare kan göra — genom modeller som RBAC (Role-Based Access Control) och principer som minsta behörighet. Korrekt åtkomstkontroll är kritisk, eftersom bruten åtkomstkontroll är OWASP:s #1-sårbarhet.
Åtkomstkontrollmodeller
RBAC (Role-Based Access Control) → assign users to ROLES; roles have PERMISSIONS:
→ user → role(s) (admin, editor, viewer) → permissions → access decisions
→ manageable, common; change a role's permissions, all its users update
ABAC (Attribute-Based) → decisions based on ATTRIBUTES (user, resource, context) → flexible,
fine-grained (e.g. "editors can edit docs in their department during business hours")
ACLs → per-resource lists of who can do what
Principen om minsta behörighet
LEAST PRIVILEGE → grant the MINIMUM access needed to do the job, nothing more:
→ limits the BLAST RADIUS if an account/component is compromised
→ applies to users, services, processes, database accounts, API keys, etc.
→ a foundational security principle (default to LESS access; grant more only as needed)
Implementering av åtkomstkontroll på ett säkert sätt
⚠️ BROKEN ACCESS CONTROL is OWASP #1 — common and serious:
✓ ENFORCE authorization on the SERVER for EVERY protected action/resource (never trust
the client; don't rely on hiding UI elements)
✓ Check the user is authorized for the SPECIFIC resource (prevent IDOR — accessing
others' data by changing an ID)
✓ DENY by default; verify on each request; centralize authorization logic
✓ Test access control (a common gap — easy to miss authorization checks)
Varför det är viktigt
Att förstå åtkomstkontroll är viktigt eftersom det styr vad användare kan göra och är kritiskt för säkerhet — bruten åtkomstkontroll är OWASP:s #1-sårbarhet — så det är värdeful, praktisk-kritisk säkerhetskompetens.
Åtkomstkontroll avgör vad autentiserade användare tillåts göra, och att få det rätt är väsentligt.
Att förstå modellerna — RBAC (tilldelning av användare till roller som har behörigheter — hanterbar och vanlig), ABAC (attributbaserade beslut för flexibel, finkornig kontroll), och ACL:er (per-resurs behörighetlistor) — ger ramverk för att strukturera behörigheter, där RBAC är vanligast att förstå.
Att förstå principen om minsta behörighet — att bevilja minsta åtkomst som behövs, vilket begränsar explosionsradien om ett konto eller en komponent äventyras — är en grundläggande säkerhetsprincip som tillämpas brett (användare, tjänster, databaskonton, API-nycklar), och ett av de viktigaste säkerhetskoncepnen.
Kritiskt, att förstå hur man implementerar åtkomstkontroll på ett säkert sätt tar itu med #1-sårbarheten: att tillämpa auktorisering på servern för varje skyddad åtgärd (aldrig lita på klienten eller förlita sig på dold UI — ett vanligt misstag), kontrollera auktorisering för den specifika resursen (förhindra IDOR, där användare får åtkomst till andras data genom att ändra ett ID — en vanlig bruten-åtkomstkontroll-fel), neka som standard, verifiera på varje förfrågan, och testa åtkomstkontroll (en vanlig brist, eftersom saknade auktoriseringskontroller är lätta att missa).
Eftersom åtkomstkontroll styr vad användare kan göra och bruten åtkomstkontroll är toppåtgärden (vanlig och allvarlig), och eftersom förståelse för modellerna (RBAC), minsta-behörighet-principen, och säker implementering (server-side-tvingande, resursspecifika kontroller, neka-som-standard) är kritisk för säkerhet, är förståelse för åtkomstkontroll värdeful, praktisk-kritisk säkerhetskompetens — som tar itu med #1-säkerhetrisken, fundamental för att kontrollera vad användare kan göra, och väsentlig för att undvika bruten-åtkomstkontroll-felaktigheterna (som IDOR och saknade auktoriseringskontroller) som är bland de vanligaste och allvarligaste sårbarheterna.