9.4 KiB
title, source_type, url, archive_url, status, confidence, related_branches, related_projects, tags, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | related_branches | related_projects | tags | created | last_reviewed | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| OWASP Authorization Cheat Sheet — Deny by default & PEP principles | official-doc | https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html | raw | high |
|
|
|
2026-05-22 | 2026-05-27 |
OWASP Authorization Cheat Sheet
Layer:
raw/official-docs/— OWASP Foundation 발행의 정식 cheat sheet. ca-skeleton AuthN/AuthZ matrix 12행의 "deny by default", "401 vs 403 분리", "every request 검증" 원칙의 1차 근거.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-security-operational-baseline | 401 (AUTH) vs 403 (AUTHZ) 분리 + deny-by-default + every-request 검증 baseline 의 운영 원칙 근거 |
| raw/branch-notes/feature-management-actuator-security-contract | actuator endpoint deny-by-default + server-side gateway 검증 결정 근거 |
컨텍스트 / 왜 저장했는지
ca-tmpl AuthN/AuthZ matrix 12행이 "왜 권한 부족은 403이고 token 누락은 401인가", "왜 default 가 deny 인가" 를 정당화하려면 RFC 외에도 운영 원칙 의 1차 출처가 필요. OWASP 는 그 역할.
출처 / Source
- 원본 URL: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
- 아카이브 URL: (미수집)
- 저자 / 조직: OWASP Foundation (Cheat Sheet Series — 커뮤니티 합의 + foundation 발행)
- 발행일: rolling docs
- 마지막 확인일: 2026-05-27
핵심 인용 / Key quotes (verbatim)
[§Introduction] "Authorization may be defined as 'the process of verifying that a requested action or service is approved for a specific entity'... Authorization is distinct from authentication which is the process of verifying an entity's identity."
[§Deny by Default] "The application must always make a decision, whether implicitly or explicitly, to either deny or permit the requested access."
[§Deny by Default] "For security purposes an application should be configured to deny access by default."
[§Enforce Least Privileges] "Least Privileges refers to the principle of assigning users only the minimum privileges necessary to complete their job."
[§Enforce Least Privileges] "Least Privileges must be applied both horizontally and vertically."
[§Validate the Permissions on Every Request] "Permission should be validated correctly on every request, regardless of whether the request was initiated by an AJAX script, server-side, or any other source."
[§Verify that Authorization Checks are Performed in the Right Location] "Developers must never rely on client-side access control checks... Access control checks must be performed server-side, at the gateway, or using serverless function."
[§Ensure Lookup IDs are Not Accessible Even When Guessed or Cannot Be Tampered With] "This type of vulnerability also represents a form of Insecure Direct Object Reference (IDOR)."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| OWASP-AUTHZ-C1 | application 은 항상 (implicit 이든 explicit 이든) access 요청에 대해 deny 또는 permit 결정을 해야 함 — 결정 부재 자체가 보안 결함 | [§Deny by Default] "The application must always make a decision, whether implicitly or explicitly, to either deny or permit the requested access." | official-reference (OWASP cheatsheet — 표준 아님) |
모든 authorization 경로 설계 | 결정 부재 시 default 가 deny 여야 한다 는 별도 권고 — 다음 claim 참조 |
| OWASP-AUTHZ-C2 | 보안 목적상 application 은 default 가 deny 로 설정되어야 함 (deny-by-default) | [§Deny by Default] "For security purposes an application should be configured to deny access by default." | official-reference |
Spring Security anyRequest().authenticated() / deny-by-default config |
"should" 권고 — 모든 framework 가 이를 default 로 강제한다는 뜻은 아님 |
| OWASP-AUTHZ-C3 | Authorization 은 entity 의 identity 를 확인하는 authentication 과 distinct — 별도 layer | [§Introduction] "Authorization is distinct from authentication which is the process of verifying an entity's identity." | official-reference |
401 (authn) vs 403 (authz) 분리 결정 | 401 vs 403 의 정확한 HTTP semantics — RFC 7235 / 9110 위임 |
| OWASP-AUTHZ-C4 | Least Privileges 원칙: user 에게 직무 수행에 필요한 minimum privileges 만 부여. horizontally and vertically 모두 적용 | [§Enforce Least Privileges] "Least Privileges refers to the principle of assigning users only the minimum privileges necessary to complete their job." + "Least Privileges must be applied both horizontally and vertically." | official-reference |
role/permission 설계 | 구체적 RBAC vs ABAC 선택 권고는 별도 섹션 (Prefer ABAC over RBAC) |
| OWASP-AUTHZ-C5 | Permission 은 every request 에서 검증되어야 함. AJAX / server-side / 기타 source 에 관계없이 | [§Validate the Permissions on Every Request] "Permission should be validated correctly on every request, regardless of whether the request was initiated by an AJAX script, server-side, or any other source." | official-reference |
stateless JWT 검증을 모든 요청에 수행하는 baseline 정합 | session caching 이 금지된다는 뜻은 아님 — 검증 결과의 staleness 가 핵심 |
| OWASP-AUTHZ-C6 | Access control check 는 never client-side 에 의존 금지. server-side, gateway, serverless function 에서 수행 | [§Verify that Authorization Checks are Performed in the Right Location] "Developers must never rely on client-side access control checks... Access control checks must be performed server-side, at the gateway, or using serverless function." | official-reference |
gateway/WAF + app envelope 결정 (ca-tmpl) | gateway 만으로 충분하다는 뜻은 아님 — app envelope 도 권장 (defense in depth) |
| OWASP-AUTHZ-C7 | lookup ID 가 guess 가능/tamper 가능한 형태이면 Insecure Direct Object Reference (IDOR) 취약점에 해당 | [§Ensure Lookup IDs are Not Accessible...] "This type of vulnerability also represents a form of Insecure Direct Object Reference (IDOR)." | official-reference |
resource ID 노출 정책 (UUID vs sequential ID 등) | BOLA (Broken Object Level Authorization) 와의 정확한 관계 — OWASP API Top 10 별도 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
OWASP-AUTHZ-C1~C7: deny-by-default, authn/authz 분리, least privilege, every-request 검증, server-side enforcement, IDOR 분류 — ca-tmpl matrix 12행의 운영 원칙 layer.
- 이 자료가 증명하지 않는 것:
- 401 vs 403 의 정확한 HTTP semantics — RFC 7235 / RFC 9110 (HTTP) 위임.
- JWT claim 검증의 구체 절차 — RFC 7519 (JWT) 위임.
- Spring Security 의 default 가 deny 인지 — Spring 벤더 doc 별도 확인.
- OWASP cheatsheet 는 "권고" 이며 강제 표준이 아님. RFC / 벤더 doc 보다 normative 권위 낮음.
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의
public path화이트리스트 정의 — deny-by-default 와의 명시적 예외 목록. - matrix 12행 중 403 boundary case (예: token valid + permission 없음 vs token valid + scope mismatch) 의 status code 선택 — cheatsheet 는 가이드만 제공.
- gateway 와 app envelope 의 책임 분리 (WAF rule vs Spring Security filter chain).
- ca-tmpl 의
메모 / Notes (내 프로젝트 해석)
본 섹션은 자료 직접 인용 아님. ca-tmpl baseline 해석.
- ca-tmpl baseline 과의 매핑:
- "Deny by Default" → Spring Security
anyRequest().authenticated()기본값과 일치. baseline 의public path misconfiguration → 500 + P1 alert결정의 근거. - "Authorization is distinct from authentication" → ca-tmpl 이 AUTH(401) 와 AUTHZ(403) 을 별도 category 로 분리한 것의 정합성 근거.
- "every request" 검증 → JWT stateless 검증을 모든 요청에 수행하는 baseline 정합.
- "server-side ... at the gateway" → ca-tmpl gateway/WAF 결정과 일치 (app envelope + gateway bypass 인정).
- "Deny by Default" → Spring Security
- 장점 (참조 권고로서):
- 광범위한 커뮤니티 합의.
- 구체적 attack vector (IDOR, BOLA) 와 연결되어 실전성 있음.
- 단점 / 한계:
- "Cheat sheet" 는 권고이며 강제 표준이 아님.
- 구현 디테일 (예: 401 vs 403 의 boundary case) 에 대한 미세 결정은 application 이 가져야 함.
- 참조 위치:
- OWASP 는 ca-tmpl baseline 의 결정 정당화 layer 이며, 구체적 status code/category 는 RFC 7519 + RFC 7235(HTTP authn) + Spring Security 를 따름.
Related / 관련
- 같은 주제 다른 official-doc:
- raw/official-docs/security-jwt-rfc-7519-validation (JWT claim 검증 표준)
- raw/official-docs/spring-security-resource-server-jwt (Spring 벤더 deny-by-default config)
- 인용하는 branch:
- 인용하는 wiki: (미작성)