llm-wiki/raw/official-docs/security-authorization-cheatsheet-owasp.md

---
title: OWASP Authorization Cheat Sheet — Deny by default & PEP principles
source_type: official-doc
url: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
archive_url:
status: raw
confidence: high
related_branches: [feature-security-operational-baseline, feature-management-actuator-security-contract]
related_projects: [ca-skeleton]
tags: [ca-security, authorization, owasp, deny-by-default, least-privilege, official-doc]
created: 2026-05-22
last_reviewed: 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).

## 메모 / 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 인정).
- **장점 (참조 권고로서)**:
  - 광범위한 커뮤니티 합의.
  - 구체적 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:
  - [[raw/branch-notes/feature-security-operational-baseline]]
  - [[raw/branch-notes/feature-management-actuator-security-contract]]
- 인용하는 wiki: (미작성)