478. Broken Access Control (취약한 접근 제어)

핵심 인사이트 (3줄 요약)

본질: 취약한 접근 제어(Broken Access Control)는 사용자가 로그인은 잘했지만(인증 통과), "네가 감히 남의 글을 지우거나 관리자 메뉴에 들어갈 자격(권한)이 있는가?"를 검증하는 뒷단 로직(인가, Authorization)을 개발자가 멍청하게 빼먹어서 발생하는 최악의 논리적 보안 결함이다.

가치: 2021년 OWASP Top 10에서 대망의 1위를 차지했다. 프레임워크(JPA 등)가 웬만한 문법 해킹(SQL 인젝션)은 다 막아주는 현대 클라우드 시대에, 프레임워크가 절대 대신 짜줄 수 없는 **'비즈니스 로직 설계의 가장 근본적인 인간의 맹점'**을 찌르며 회사의 DB를 통째로 털어먹는 가장 치명적이고 빈번한 재앙이다.

융합: 프론트엔드의 화면 버튼만 숨기는 눈속임 방어를 철저히 파괴(Bypass)하며, 이를 막기 위해 백엔드 API(서버 코어) 단에서 데이터 소유주를 무조건 재검증하는 접근 통제 리스트(ACL), 역할 기반 통제(RBAC) 및 제로 트러스트(Zero Trust) 아키텍처와 생사를 걸고 융합되어야 한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 시스템 보안의 양대 산맥은 "너구구냐?(인증, Authentication)"와 "너 그거 할 자격 있어?(인가, Authorization / Access Control)"다. 해커가 정상적인 일반 유저로 로그인을 했다. 그런 뒤 브라우저 주소창에서 http://bank.com/account?id=123 (내 계좌)의 뒷번호를 ?id=124로 슥 바꿨다. 띠용? 남의 계좌 정보와 100억 잔고가 화면에 그대로 뜬다. 서버가 "어? 로그인한 유저네? 그냥 보여줘!"라며 그 계좌의 '주인(Owner)'이 맞는지 검사하는 단 1줄의 if문을 빼먹은 것, 이게 바로 Broken Access Control의 적나라한 실체다.
필요성: 개발자들은 프론트엔드 화면에서 '관리자 메뉴 버튼'을 일반 유저에게 안 보이게 숨기면(UI Hiding) 보안이 끝난 줄 안다(최악의 착각). 해커는 버튼 따위는 누르지 않는다. 프록시 툴(Burp Suite)로 백엔드 API URL(/admin/deleteUser)을 직접 찔러버린다. 뒷문(백엔드)에서 깐깐한 경비원(접근 제어 로직)이 "이봐, 당신 관리자 맞아?"라고 막아서지 않으면 시스템의 심장부가 무혈입성으로 털린다. 눈에 보이는 껍데기가 아니라 보이지 않는 진짜 데이터의 빗장을 걸어 잠그기 위해 절대적인 방어 철학이 필요하다.
💡 비유: 취약한 접근 제어는 **'신분증만 보고 펜트하우스 열쇠를 내주는 호텔 프론트'**와 같습니다. 손님이 호텔 정문(로그인)을 통과했습니다(인증 완료). 손님이 프론트에 가서 "저 1004호 VIP 펜트하우스 키 주세요"라고 당당하게 요구합니다. 멍청한 직원(취약한 서버)은 "아, 우리 호텔 손님이시군요! 여기 있습니다!"라며 그냥 내어줍니다. 진짜 유능한 직원은 "손님, 투숙 명단(권한/인가)을 보니 1004호 예약자가 아니신데요? 경비원!"이라며 쫓아내야 합니다. 이 투숙 명단 확인(권한 검증)을 빼먹는 대형 사고가 바로 Broken Access Control입니다.
등장 배경 및 발전 과정:
1. 단순 인증의 시대: 과거엔 ID/PW 뚫는 것 자체가 힘들어, 로그인만 통과하면 내부망은 신뢰(Trust)하는 바보 같은 낭만의 시대였다.
2. IDOR (안전하지 않은 직접 객체 참조)의 유행: 2010년대 해커들이 URL 파라미터(id=1 -> id=2)만 바꾸면 남의 정보가 술술 새어 나오는 마법의 꿀통(IDOR)을 발견하고 미친 듯이 털어먹기 시작했다. (웹 해킹의 르네상스)
3. OWASP 부동의 1위 지배 (현재): 클라우드와 MSA로 API 통신이 수천 개로 폭발하면서, 모든 API 구멍마다 권한(인가)을 깐깐히 체크하는 것을 개발자들이 빼먹기 시작했다. 결국 인젝션(Injection)을 밀어내고 2021년 영광의 해킹 수법 1위 왕좌에 등극했다.
📢 섹션 요약 비유: 이것은 **'도둑이 아니라 뻔뻔한 위장 손님'**을 막는 일입니다. 창문을 깨고 들어오는 도둑(인젝션)은 프레임워크(방범창)가 막아줍니다. 하지만 멀쩡하게 카드를 찍고 들어온 손님이, 갑자기 사장님 의자에 앉아서 금고 비밀번호를 바꾸려 할 때(권한 상승), 그 자리에서 멱살을 잡고 끌어내리는 보이지 않는 내부 경호원(접근 제어 로직)이 없으면 회사는 그날로 파산합니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. Broken Access Control의 3가지 멸망 시나리오 (해커의 침투 경로)

해커는 3가지 방향으로 당신의 권한을 훔쳐 간다.

수평적 권한 상승 (IDOR: Insecure Direct Object References)
- 원리: 나(일반 유저)와 똑같은 레벨에 있는 다른 일반 유저의 자원을 훔쳐봄.
- 공격: 내 장바구니 URL cart?user_id=me를 cart?user_id=rich_guy로 바꿨더니 부자 유저의 장바구니가 털림.
수직적 권한 상승 (Elevation of Privilege)
- 원리: 일반 유저(하급)가 관리자(상급)의 금단 구역으로 엘리베이터를 타고 올라감.
- 공격: http://site.com/user/profile에 있던 URL을 해커가 눈치껏 http://site.com/admin/settings로 쳤더니 관리자 설정 창이 훅 열림.
CORS (Cross-Origin Resource Sharing) 설정 오류
- 원리: 나쁜 놈이 만든 사기 사이트에서, 내 뱅킹 서버 API를 호출했는데 서버가 막지 않고 고객 정보를 바쳐버림. "어느 도메인(Origin)에서 날 찌르는지" 출입증 검사를 멍청하게 한 죄.

2. 아키텍처 방어의 성배: 중앙 집중식 인가(Authorization) 필터

개발자 백 명에게 "제발 함수마다 if (이글의 주인 == 로그인유저) 꼼꼼히 짜!"라고 백날 잔소리해봤자 무조건 빼먹는다. 인간을 믿지 말고 아키텍처(구조)로 틀어막아야 한다.

[ 해커의 악의적 API 요청 ]
        │ 
        ▼
================== [ AOP / Interceptor / API Gateway (중앙 수문장) ] ==================
 1단계: "이 URL(/admin/*)은 관리자 롤(Role) 배지 없으면 당장 403 에러 뱉고 꺼져!" (RBAC)
 2단계: "글 삭제 API야? 그럼 이 세션의 유저가 진짜 이 글의 작성자(Owner)가 맞는지 
         DB 1번 찔러서 소유권 일치 여부 무조건 검사해!" (ABAC / 소유권 검증)
=======================================================================================
        │ (위의 혹독한 검증을 통과한 순결한 패킷만 통과)
        ▼
[ 진짜 비즈니스 로직 (Controller / Service) ]

핵심 원리: 컨트롤러(Controller)나 서비스(Service) 깊숙한 곳에서 권한을 체크하면 이미 늦거나 개발자가 빼먹기 십상이다. 아키텍트는 아예 **모든 패킷이 무조건 거쳐 가야 하는 맨 앞단의 단일 병목점(Interceptor, Spring Security 등)**에서 전역적으로, 기계적으로 권한을 틀어막는(Default Deny) 융합 방어망을 깔아야 한다.
📢 섹션 요약 비유: 수평/수직 권한 상승은 **'병원 병실 탈탈 털기'**와 같습니다. 환자(유저)가 입원 수속(로그인)을 밟았습니다. 수평적 탈취는 내 병실 301호에 안 있고 옆방 302호 환자 차트를 훔쳐보는 것이고, 수직적 탈취는 아예 의사 가운을 훔쳐 입고 수술실(관리자 메뉴)로 무단 침입하는 것입니다. 간호사(API 게이트웨이)가 길목마다 명찰(토큰)을 깐깐하게 검사하지 않으면 병원은 난장판이 됩니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 인증(Authentication) vs 인가(Authorization)

해킹 방어의 가장 기본이면서도 주니어들이 가장 많이 헷갈리는 절대 개념.

척도	인증 (Authentication, AuthN)	인가 / 접근 제어 (Authorization, AuthZ)
질문 (Question)	"너 누구야?" (Who are you?)	"너 그거 해도 돼?" (Are you allowed to do this?)
확인 수단	ID/비밀번호, 지문, 2FA(OTP)	RBAC(역할/등급), ACL(접근 제어 목록), JWT 토큰 안의 Role
방어 위치	시스템 맨 앞 정문 (로그인 화면)	시스템 내부의 모든 방문과 서랍 앞 (모든 API 앞)
실패 시 에러 코드	`401 Unauthorized` (로그인 안 됨 꺼져)	`403 Forbidden` (로그인은 했지만 권한이 없음 꺼져)
해킹 시나리오	뚫리면 그냥 남의 아이디로 들어가는 것	로그인 통과 후(인증 성공), 방어막이 풀린 줄 알고 남의 데이터를 마구 헤집고 다니는 것 (Broken Access Control)

과목 융합 관점

아키텍처 (클라이언트 vs 서버의 진실 공방): Broken Access Control이 터지는 가장 멍청한 이유는 아키텍처 관점에서 **'클라이언트(프론트엔드)를 믿었기 때문'**이다. 개발자가 "프론트 화면에서 관리자 아니면 삭제 버튼 안 보이게 숨겼어. 그러니까 서버 쪽 API(POST /delete)엔 권한 검사 굳이 안 짜도 되겠지?"라고 방심한다. 해커는 버튼 따위는 무시하고, Postman(API 찌르는 툴)으로 서버의 알몸(API)을 다이렉트로 때린다. **"절대로 프론트엔드의 방어를 믿지 마라. 진실(검증)은 오직 백엔드 서버(API)에서만 이루어져야 한다"**는 클라이언트-서버 분리 설계의 대원칙이 폭발하는 지점이다.
데이터베이스 (BOLA 방어): 데이터베이스의 Primary Key(PK) 설계와도 융합된다. 유저 번호를 id=1, id=2 같은 뻔한 정수(Auto Increment)로 만들면, 해커가 숫자만 1, 2, 3으로 1초에 1만 번 돌리며(스크래핑) 남의 정보를 다 털어간다(BOLA: Broken Object Level Authorization). 이를 막기 위해 아키텍트는 애초에 DB PK나 API 노출 파라미터를 유추가 100% 불가능한 UUID (550e8400-e29b-41d4...) 형식으로 암호화하여 매핑함으로써, 권한이 뚫려도 해커가 다음 타겟의 주소를 몰라 털지 못하게 만드는 심층 방어(DB + API 융합)를 전개한다.
📢 섹션 요약 비유: **인증(AuthN)**은 공항에서 "이 여권 네 거 맞아?" 하고 신분증을 확인하는 것입니다. 통과하면 비행기를 탈 수 있습니다. **인가(AuthZ)**는 비행기를 타고 나서, 이코노미석 표를 산 사람(일반 유저)이 일등석(관리자 구역) 빈자리에 쓱 가서 눕거나, 조종석 문을 열고 들어가려 할 때 승무원(서버)이 표를 검사하고 쫓아내는 행위입니다. 비행기 안에 들어왔다고 끝이 아닙니다. 내부의 선 긋기가 진정한 접근 제어입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — JWT 토큰(Token)의 오해와 서명 무시의 참극: 프론트엔드가 백엔드에 요청할 때 JWT 토큰(eyJhb...)을 쏜다. 토큰 안에는 해시로 인코딩된 {"user_id": "alex", "role": "user"} 라는 내용이 들어있다. 해커가 이 토큰을 쓱 긁어서, Base64 디코딩 웹사이트에 넣고 role을 "admin"으로 슬쩍 고친 뒤 쏘았다. 멍청한 백엔드 개발자는 이 토큰의 서명(Signature) 유효성을 위변조 검사 로직(Verify) 없이 그냥 디코딩해서 읽기만 했다. 서버는 "오! 어드민이시네예!"라며 금고 문을 열어버렸다.
- 아키텍트의 해결책: JWT(무상태 인증) 아키텍처의 서명 검증(Validation) 파탄이다. 토큰의 내용은 누구나 읽을 수 있다(암호화된 게 아니다). 중요한 건 그 내용이 '변조되지 않았음'을 증명하는 맨 뒷부분의 서명(Signature)이다. 아키텍트는 API 게이트웨이나 인터셉터 단에 **"토큰이 날아오면 묻지도 따지지도 말고, 서버만 알고 있는 비밀 키(Secret Key)로 서명 무결성부터 검증하여, 1글자라도 변조된 놈이면 즉각 401 Unauthorized로 튕겨버려라"**는 중앙 통제 모듈(Spring Security Filter)을 강제로 박아 넣어야 이 어처구니없는 조작극을 막는다.
시나리오 — 숨겨진 디렉토리(Directory Traversal) 폭격과 관리자 파일 유출: 해커가 쇼핑몰에서 상품 이미지를 다운로드받는 URL http://shop.com/download?file=apple.jpg 를 유심히 쳐다본다. 그리고 파라미터에 file=../../../../etc/passwd (리눅스 최고 비밀 파일) 라고 소름 끼치는 점(Dot) 공격을 날린다. 서버의 코드는 File f = new File(uploadPath + userInput) 이라고 허술하게 짜여 있었다. 폴더를 뒤로 4번 후진(Traverse)한 코드는, 웹 루트를 뚫고 나가 리눅스 OS의 심장부 파일까지 화면에 텍스트로 줄줄 뱉어내 버렸다.
- 아키텍트의 해결책: 직접 객체 참조(Direct Object Reference) 허용이 부른 전형적인 접근 제어 파탄이다. 절대 외부의 클라이언트가 던지는 '파일명'이나 '경로'를 그대로 서버의 하드디스크 경로에 붙여서(Concatenation) 읽게 만들면 안 된다. 아키텍트는 클라이언트가 간접적인 난수 매핑키(id=1948)만 던지게 하고, 서버 안의 안전한 DB 맵을 찔러 "아 1948번은 apple.jpg 구나"라고 매핑해서 꺼내주는 간접 참조(Indirect Reference) 구조로 뼈대를 완전히 갈아엎거나, 입력값에서 ../ 나 / 같은 특수문자를 악성 코드로 간주하고 100% 튕겨내는 화이트리스트(Whitelist) 검증 필터를 이중으로 둘러쳐야 한다.

도입 체크리스트

설계적: "기본 거부 (Deny by Default)" 원칙을 아키텍처에 깔았는가? "이 API는 관리자만 들어오게 짜야지!"라고 생각하면 개발자가 깜빡하고 예외 처리를 빼먹는 순간 해커의 놀이터가 된다. 아키텍처의 패러다임은 반대여야 한다. "모든 API는 기본적으로 전 우주의 모든 접근을 다 차단한다(403 Forbidden). 그리고 내가 특별히 @PermitAll이나 @Role('USER')라고 허락(White-list)의 도장을 찍어준 놈들만 예외적으로 길을 열어준다." 이 숨 막히는 폐쇄주의만이 개발자의 실수(Human Error)를 기계적으로 덮어주는 완벽한 방패다.
비즈니스적: 기능 권한(RBAC)을 넘어 데이터 소유권(ABAC/PBAC)까지 검증하는가? "너 회원 맞아?" -> "너 이 게시판 읽을 등급(Role) 돼?" 여기까지는 RBAC로 다 짠다. 가장 많이 털리는 건 마지막 3단계, **"등급은 되는데, 지금 네가 열어달라고 한 45번 글(Data)의 진짜 주인이 너 맞아?"**를 묻는 속성 기반 권한 통제(ABAC)다. 컨트롤러에 들어오자마자 DB를 1번 찔러서 if (article.getOwnerId() != session.getUserId()) throw Exception; 코드가 무조건 최상단에 박혀있는지 코드 리뷰(Code Review)에서 현미경처럼 잡아내야 한다.

안티패턴

보안에 의한 모호성 (Security through Obscurity) 맹신: 관리자 페이지 URL을 남들이 절대 예측 못 할 거라고 믿고 http://site.com/super_secret_admin_1234 로 파놓은 뒤 권한 체크(인가)를 안 짜는 무식함. 해커가 폴더 스캐닝 도구(DirBuster)를 돌리거나, 직원이 구글 검색을 통해 1초 만에 URL이 뽀록나면 그대로 프리패스로 뚫리는 최악의 눈 가리고 아웅 식 안티패턴. 해커에게 도면과 URL이 100% 털렸다는 전제하에서도 당당히 막아내는 인가 로직이 진짜 아키텍처다.
📢 섹션 요약 비유: 접근 제어를 숨김(Obscurity)으로 때우려는 것은, 집 문에 **'자물쇠를 안 채우고 열쇠 구멍에 껌딱지 붙여서 숨겨놓는 것'**과 같습니다. 강도가 구멍을 못 찾을 땐 안전해 보입니다. 하지만 강도가 발로 문을 한 번 쾅 차보는 순간(URL 직접 호출), 자물쇠가 없다는 사실이 뽀록나며 1초 만에 털립니다. 해커가 자물쇠를 눈으로 빤히 보고 있어도, 열쇠(토큰/권한)가 없으면 절대 따지 못하게 철골 자물쇠(인가 로직)를 거는 것이 진짜 보안입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	프론트엔드 버튼 숨김에 의존하는 허술한 제어 (AS-IS)	백엔드 API 중앙 필터 및 소유권 재검증(ABAC) 강제 (TO-BE)	개선 효과
정량	파라미터 변조(`id=1->2`)로 남의 데이터 유출 연 10건	DB PK의 UUID 암호화 및 Owner 비교로 우회 공격 0건	IDOR 및 수평적 권한 상승(해킹) 사고 100% 무결점 차단
정량	각 함수마다 개발자가 권한 체크 짜느라 코드량 30% 폭증	Spring Security 등 중앙 1곳에서 공통 제어 후 넘겨줌	권한 제어 코드의 파편화 소멸 및 보안 유지보수 시간 90% 압축
정성	"이 URL 관리자 권한 걸어놨나?" 개발자마다 기준 다름	`@PreAuthorize("hasRole('ADMIN')")` 명시적 룰의 강제화	누락 없는 보안 정책의 통일 및 개발자 간 완벽한 투명성 획득

미래 전망

제로 트러스트(Zero Trust)의 절대 지배: 과거의 접근 제어는 "VPN(사내망) 뚫고 들어왔어? 그럼 넌 안전한 직원이지! 패스!"라는 경계형 보안이었다. 미래는 제로 트러스트, 즉 "네가 사장님 자리에서 접속하든 사내망이든 1도 안 믿어! 파일 1개 열 때마다, 폴더 1개 지울 때마다 네가 그 짓을 할 권한(인가)이 있는지 미친 듯이 매번 깐깐하게 다시 검사할 거야!"라는 극단적인 지속적 접근 제어(Continuous Access Evaluation) 아키텍처가 전 세계 기업망을 통째로 뜯어고치고 있다.
AI 기반의 맥락 인지형 권한 제어 (Context-Aware Access Control): 단순히 직급(Role)만 보고 문을 열어주는 시대는 끝난다. AI가 유저의 평소 습관을 분석하다가, "김 과장이 맞긴 한데... 평소에 낮 12시에 강남에서 접속하던 사람이, 갑자기 새벽 3시에 아프리카 IP로 접속해서 고객 DB 1만 건 엑셀 다운로드를 누르네? 이건 미친 짓이야!"라며 정상 권한을 가진 자라도 그 '상황(Context)'이 비정상적이면 AI가 스스로 판단하여 찰나에 다운로드 버튼의 권한을 강제 락(Lock) 걸어버리는 지능형 인가 시스템이 도래했다.

참고 표준

OWASP Top 10 (A01: Broken Access Control): 인류 소프트웨어 해킹 역사상, SQL 인젝션의 아성을 무너뜨리고 2021년 1위로 군림한 가장 무식하고도 치명적인 논리 버그의 제왕. (이전 장 477번)
RBAC (Role-Based Access Control) & ABAC (Attribute-Based Access Control): 접근 제어를 짤 때 주먹구구식 if문을 없애고, "넌 일반 유저 롤(Role)이네? 안 돼!"(RBAC)에서 진화하여 "넌 관리자 롤이긴 한데, 지금 근무 시간이 6시 넘었네(속성, Attribute)? 퇴근했으니까 파일 열람 안 돼!"(ABAC)로 진화하는 전 세계 공통 권한 통제 프레임워크 표준.

취약한 접근 제어(Broken Access Control)는 소프트웨어 공학이 방치한 **'인간(개발자)의 게으름이 낳은 가장 거대한 파멸의 구멍'**이다. 해커는 바보가 아니다. 뚫리지 않는 튼튼한 방화벽이나 최첨단 암호화 로직(정문)을 정면으로 때리지 않는다. 대신 개발자가 피곤해서 깜빡 잊고 열어둔 "권한 체크 없는 텅 빈 API 경로(개구멍)"로 너무나 평온하게 걸어 들어와 금고를 쓸어 담는다. 기술사는 프론트엔드의 화려한 화면 뒤에 숨겨진 백엔드의 모든 API 입구마다, 1년 365일 잠들지 않는 무자비한 '로봇 경비원(Interceptor/Filter)'을 강제로 세워두어야 한다. "아무리 완벽하게 로그인한 자라도, 완벽하게 증명하지 않으면 단 1바이트의 데이터도 허락하지 않겠다"는 극도의 폐쇄성(Deny by Default), 그것만이 이 허무하고도 끔찍한 1위의 해킹 재앙으로부터 1,000만 고객의 목숨을 지켜내는 가장 무겁고도 위대한 철문이다.

📢 섹션 요약 비유: 깨진 접근 제어(Broken Access Control)는 미술관의 **'레이저 도난 경보기 꺼놓기'**와 같습니다. 정문에 경비원(로그인)이 서 있으면 뭐합니까? 손님으로 위장해 들어온 도둑이 모나리자 그림(남의 데이터) 쪽으로 성큼성큼 다가가 그림을 액자에서 떼어내려는데(권한 없는 행위), 그림 주변에 쳐진 붉은색 레이저 경보기(접근 제어/인가 로직)가 귀찮다고 꺼져있다면 아무런 경보도 울리지 않고 속수무책으로 털리는 것입니다. 모든 핵심 그림 앞에는 개별적인 레이저(API 검증)가 촘촘히 켜져 있어야만 완벽한 요새가 됩니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
OWASP Top 10	이 문서(477번)에서 2021년 영광의 1위를 차지한, 현대 웹에서 가장 치명적이고 가장 많이 터지는 해킹 기법의 대명사. 프레임워크가 안 막아주니 개발자의 뇌지컬로만 막아야 하는 난제.
인증 (Authentication) / 인가 (Authorization)	인증이 "로그인 성공!"이라는 1차 관문이라면, Broken Access Control은 2차 관문인 "인가(권한 확인)"를 병신같이 짜서 로그인한 도둑에게 안방을 내어주는 대참사.
위협 모델링 (STRIDE)	STRIDE의 E(권한 상승)와 I(정보 유출)를 정확히 저격하는 공격. "해커가 남의 글의 ID를 슬쩍 바꿔서(T) 권한 상승(E)을 노리지 않을까?"라는 통찰이 이 버그를 코딩 전에 밟아 죽인다. (이전 장 474, 475번)
제로 트러스트 (Zero Trust)	"로그인한 직원도 믿지 마!" 깨진 접근 제어의 공포 때문에, 한 번 로그인 패스했다고 놔두지 않고 매 API 호출마다 권한(인가)을 미친 듯이 다시 쪼아대는 현대 아키텍처의 절대 뼈대.
API Gateway / Interceptor	개발자들이 함수마다 뿔뿔이 흩어져서 `if (권한있나?)`를 치다 빼먹는 실수를 막기 위해, 시스템 정문 입구 1곳에 몰아넣고 공통으로 칼차단을 먹이는 스프링/클라우드의 기계적 수문장.

👶 어린이를 위한 3줄 비유 설명

내가 놀이공원에 입장권(로그인)을 내고 정문으로 당당하게 들어갔어요(인증 성공).
놀이공원에 들어가서 걷다 보니 조종실이 보였는데, 내가 맘대로 **'롤러코스터 속도를 10배 올리는 버튼(관리자 권한)'**을 눌렀는데도 경호원이 막지 않고 기계가 쌩~ 하고 작동해 버렸어요!
이렇게 밖에서 들어온 건 맞지만, 안에서 절대 만지면 안 되는 남의 물건이나 스위치를 만질 때 "너 이거 누를 자격증 있어?!" 하고 검사하는 똑똑한 경호원이 없는 끔찍한 구멍을 **'취약한 접근 제어'**라고 부른답니다!