인증·인가·API 보안

4장 1절: 웹 구조, HTTP, 쿠키, 세션, 인증과 인가
4장 2절: SQL Injection
4장 3절: XSS, CSRF, 파일 업로드 취약점
4장 4절: 인증·인가·API 보안

로그인
비밀번호
세션
토큰
관리자 권한
API 인증
API 권한 검증
접근통제 취약점

인증과 인가의 차이를 설명하시오.
세션 관리 보안 대책을 설명하시오.
JWT 사용 시 보안상 주의사항을 설명하시오.
IDOR 취약점의 개념과 대응 방안을 설명하시오.
API 보안 대책을 설명하시오.
브루트포스 공격 대응 방안을 설명하시오.

1. 사용자가 로그인한다.
2. 서버가 사용자를 인증한다.
3. 서버가 세션 또는 토큰을 발급한다.
4. 사용자는 세션이나 토큰으로 계속 요청한다.
5. 서버는 매 요청마다 권한을 확인한다.
6. API는 요청값과 권한을 검증한다.
7. 이상 요청은 제한하고 로그로 남긴다.

인증은 “너 누구야?”
인가는 “너 이거 해도 돼?”
API 보안은 “모든 요청을 인증·인가·검증·기록하는 것”

인증은 사용자가 주장하는 신원이 실제로 맞는지 확인하는 절차이다.

인증 = 너 누구야?

아이디와 비밀번호 로그인
OTP 입력
공동인증서 또는 인증서 로그인
지문 인증
얼굴 인증
보안 토큰 인증

인증 요소는 지식 기반, 소유 기반, 생체 기반으로 구분할 수 있다.

MFA는 지식, 소유, 생체 등 서로 다른 인증 요소를 2개 이상 결합하여 사용자의 신원을 확인하는 인증 방식이다.

비밀번호 + OTP
비밀번호 + 인증서
비밀번호 + 지문
비밀번호 + 휴대폰 푸시 승인

피싱
악성코드
키로거
DB 유출
비밀번호 재사용
무차별 대입 공격

MFA는 비밀번호 외에 OTP, 인증서, 생체정보 등 추가 인증 요소를 요구하여 비밀번호 유출이나 추측 공격이 발생하더라도 계정 탈취 가능성을 줄이는 보안 대책이다.

비밀번호 정책에는 최소 길이, 복잡도, 재사용 제한, 사용자 정보 포함 금지, 로그인 실패 제한, 초기 비밀번호 변경, 유출 비밀번호 차단 등이 포함되어야 한다.

user01 / qwer1234
admin / admin1234

비밀번호 원문
→ 솔트 추가
→ 안전한 해시 함수 적용
→ 해시값 저장

비밀번호는 평문으로 저장하지 않고 사용자별 솔트를 적용한 해시값으로 저장해야 한다. 솔트는 동일한 비밀번호라도 서로 다른 해시값이 생성되도록 하여 사전 공격과 레인보우 테이블 공격을 어렵게 한다.

비밀번호 + 솔트 → 해시값

브루트포스 공격은 가능한 비밀번호나 인증값을 무차별적으로 반복 대입하여 올바른 값을 찾아내는 공격이다.

로그인 실패 횟수 제한
계정 잠금 정책
Rate Limiting
CAPTCHA
MFA
강력한 비밀번호 정책
로그 모니터링

password
qwer1234
admin123
company2026
birthdate

사전 단어 비밀번호 금지
사용자 정보 포함 금지
복잡도와 길이 정책
유출 비밀번호 차단

크리덴셜 스터핑은 다른 서비스에서 유출된 아이디와 비밀번호 조합을 이용하여 여러 서비스에 자동으로 로그인 시도하는 공격이다.

MFA 적용
유출 비밀번호 사용 차단
로그인 시도 Rate Limiting
비정상 로그인 탐지
동일 계정 반복 실패 탐지
새로운 위치·기기 접속 알림
비밀번호 재사용 금지 안내

크리덴셜 스터핑은 다른 서비스에서 유출된 계정 정보를 이용해 대상 서비스에 자동 로그인 시도하는 공격이다. 대응 방안으로는 MFA 적용, 유출 비밀번호 사용 차단, 로그인 Rate Limiting, 비정상 로그인 탐지, 새로운 기기·위치 접속 알림, 반복 실패 계정 모니터링 등이 있다.

로그인 보안을 위해 HTTPS를 적용하고, 비밀번호는 솔트를 적용한 해시값으로 저장해야 한다. 또한 MFA, 로그인 실패 제한, Rate Limiting, CAPTCHA, 유출 비밀번호 차단, 비정상 로그인 탐지, 로그인 후 세션 재발급, 접속 로그 모니터링을 적용해야 한다.

인가는 인증된 사용자가 허용된 권한 범위 내에서 자원이나 기능에 접근할 수 있도록 통제하는 절차이다.

인가 = 너 이거 해도 돼?

인증은 사용자의 신원을 확인하는 절차이고, 인가는 인증된 사용자가 특정 자원이나 기능에 접근할 권한이 있는지 확인하는 절차이다. 예를 들어 로그인은 인증이고, 관리자 페이지 접근 허용 여부를 판단하는 것은 인가이다.

접근통제 취약점은 인증된 사용자의 권한을 서버 측에서 적절히 검증하지 않아 다른 사용자의 자원이나 관리자 기능에 접근할 수 있는 취약점이다.

로그인은 했지만, 해도 되는 일인지 확인하지 않는 문제

IDOR는 사용자가 요청 파라미터의 객체 식별자를 조작하여 권한이 없는 다른 사용자의 자원에 접근하는 접근통제 취약점이다.

IDOR = 번호만 바꿨더니 남의 정보가 보이는 문제

/user/profile?id=100

/user/profile?id=101

요청한 id 값으로 DB 조회
→ 결과를 그대로 반환

요청한 사용자가 해당 id 자원에 접근할 권한이 있는지 확인
→ 권한이 있으면 반환
→ 권한이 없으면 403 처리

IDOR는 서버가 요청 파라미터의 객체 ID에 대해 소유자와 접근 권한을 검증하지 않을 때 발생한다.

식별자를 UUID처럼 예측 어렵게 만드는 것은 보조 대책이다.
핵심은 서버 측 권한 검증이다.

IDOR는 사용자가 요청 파라미터의 객체 식별자를 조작하여 권한 없는 타인의 자원에 접근하는 취약점이다. 대응 방안으로는 서버 측에서 매 요청마다 사용자 권한과 자원 소유자를 검증하고, 역할 기반 접근통제를 적용하며, 단순 순번 ID 노출을 줄이고, 비정상 객체 ID 순차 접근을 로그로 모니터링해야 한다.

일반 사용자가 관리자 URL 직접 접근
관리자 로그인 페이지가 외부에 그대로 노출
약한 관리자 비밀번호 사용
관리자 세션 탈취
관리자 기능에 CSRF 발생
관리자 페이지에서 XSS 실행

관리자 페이지는 MFA와 강력한 인증을 적용하고, 접근 IP 또는 VPN을 통해 접속 대상을 제한해야 한다. 또한 관리자 권한을 서버 측에서 매 요청 검증하고, 중요 작업 재인증, 세션 보안 설정, CSRF Token, 관리자 작업 로그 기록을 적용해야 한다.

세션 하이재킹
세션 고정
세션 탈취
로그아웃 후 세션 재사용
장시간 유효한 세션 악용

세션 고정 공격은 공격자가 미리 알고 있는 세션 ID를 피해자가 사용하게 만든 뒤, 피해자가 로그인하면 해당 세션을 이용해 인증된 상태를 탈취하는 공격이다.

로그인 성공 후 세션 ID 재발급

세션 보안을 위해 예측 불가능한 세션 ID를 사용하고, 로그인 성공 후 세션 ID를 재발급하여 세션 고정 공격을 방지해야 한다. 또한 HTTPS, HttpOnly·Secure·SameSite 쿠키, 세션 타임아웃, 로그아웃 시 서버 측 세션 폐기, 중요 기능 재인증, 이상 접속 탐지를 적용해야 한다.

1. 사용자가 로그인한다.
2. 서버가 토큰을 발급한다.
3. 클라이언트가 이후 요청에 토큰을 포함한다.
4. 서버는 토큰을 검증하고 요청을 처리한다.

Authorization: Bearer <token>

토큰은 비밀번호처럼 보호해야 한다.

JWT는 JSON 형식의 정보를 담고 서명을 통해 위변조 여부를 검증할 수 있는 토큰 기반 인증 방식이다.

Header.Payload.Signature

JWT는 기본적으로 서명된 토큰이지, 반드시 암호화된 토큰은 아니다.

JWT는 JSON 형식의 클레임을 담고 서명을 통해 위변조 여부를 검증할 수 있는 토큰 기반 인증 방식이다. 보안 운영을 위해 서명 검증, 안전한 알고리즘 사용, 짧은 만료시간 설정, Payload에 민감정보 저장 금지, HTTPS 전송, 토큰 탈취 대비 폐기·재발급 정책, 권한 클레임 검증이 필요하다.

GET /api/users/me
POST /api/orders
DELETE /api/posts/123

API는 모든 요청에서 인증, 인가, 입력값 검증을 서버 측에서 수행해야 한다.

프론트엔드에서 버튼을 숨겼으니 안전하다.

서버 API가 매 요청마다 권한을 검증한다.

BOLA는 API에서 특정 객체에 접근할 때 사용자에게 해당 객체 접근 권한이 있는지 확인하지 않아 발생하는 접근통제 취약점이다.

GET /api/orders/100
GET /api/orders/101

API 서버가 매 요청마다 사용자와 객체 소유권을 검증해야 한다.

{
  "name": "kim",
  "email": "kim@example.com",
  "role": "admin"
}

Mass Assignment는 서버가 클라이언트 요청 필드를 제한 없이 객체에 매핑하여 권한, 상태, 금액 등 사용자가 수정하면 안 되는 값까지 변경될 수 있는 취약점이다.

허용된 필드만 반영
DTO 사용
권한별 수정 가능 필드 제한
서버 측 중요 값 결정

Mass Assignment를 방지하기 위해 클라이언트가 보낸 모든 필드를 객체에 자동 반영하지 말고, 허용된 필드만 명시적으로 매핑해야 한다. 권한, 역할, 가격, 상태값 등 중요 필드는 서버 측에서 결정하고 권한별 수정 가능 항목을 제한해야 한다.

{
  "id": 100,
  "name": "kim",
  "email": "kim@example.com",
  "passwordHash": "...",
  "residentNumber": "...",
  "role": "user"
}

필요한 데이터만 반환
민감정보 응답 제외
권한별 응답 필드 제한
서버 측 응답 필터링

API는 클라이언트 화면에 사용되지 않는 민감정보까지 응답하지 않도록 필요한 데이터만 최소한으로 반환해야 한다.

로그인 API 반복 호출
인증번호 요청 API 반복 호출
검색 API 대량 호출
사용자 정보 API 순차 조회
주문 조회 API 반복 호출

Rate Limiting = 요청량 제한

IP별
계정별
토큰별
세션별
API Key별
URL별

브루트포스 방지
크리덴셜 스터핑 완화
API 남용 방지
DDoS 일부 완화
대량 정보 수집 방지

API Rate Limiting은 IP, 계정, 토큰, API Key, URL 등을 기준으로 일정 시간 동안 허용되는 요청 횟수를 제한하는 보안 대책이다. 이를 통해 브루트포스, 크리덴셜 스터핑, 대량 정보 수집, 자동화 공격, API 남용을 완화할 수 있다.

CORS를 너무 넓게 허용하면 허용되지 않은 사이트에서 API에 접근할 수 있다.

모든 출처 허용

신뢰할 수 있는 도메인만 허용
필요한 메서드와 헤더만 허용
인증정보 포함 요청은 특히 제한

CORS는 브라우저에서 다른 출처의 리소스 요청을 제어하는 정책이며, API 보안을 위해 신뢰할 수 있는 출처만 허용하고 필요한 메서드와 헤더만 제한적으로 허용해야 한다.

API 보안을 위해 모든 요청에 인증을 적용하고, 사용자가 요청한 자원에 접근할 권한이 있는지 서버 측에서 검증해야 한다. 또한 입력값 검증, 응답 데이터 최소화, Rate Limiting, 토큰 만료와 폐기 정책, Mass Assignment 방지, CORS 제한, 오류 메시지 노출 제한, API 호출 로그 기록을 적용해야 한다.

API 로그에서 동일 사용자가 객체 ID를 순차적으로 변경하며 조회하고 403 응답이 반복된다면 IDOR 또는 접근통제 우회 시도로 의심할 수 있다. 대응 방안으로 서버 측 객체 소유권 검증, 권한 정책 점검, Rate Limiting, 비정상 요청 차단, 로그 모니터링을 수행해야 한다.

1. 사용자가 로그인한다.
2. 서버는 비밀번호를 검증하고 MFA를 확인한다.
3. 로그인 성공 후 세션 또는 토큰을 발급한다.
4. 사용자가 주문 내역 API를 호출한다.
5. 서버는 토큰을 검증한다.
6. 서버는 해당 주문이 그 사용자의 주문인지 확인한다.
7. 필요한 데이터만 응답한다.
8. 요청과 응답 결과를 로그로 남긴다.

주문번호만 바꾸면 타인의 주문 조회 가능 → IDOR
토큰 만료시간 없음 → 탈취 시 장기간 악용
API 요청 횟수 제한 없음 → 대량 조회 가능
사용자가 role=admin 값을 보내면 반영됨 → Mass Assignment
응답에 passwordHash 포함 → 과도한 데이터 노출

서버 측 인증 검증
객체 소유권 검증
권한별 응답 데이터 제한
토큰 만료와 서명 검증
Rate Limiting
Mass Assignment 방지
API 로그 모니터링

인증은 사용자가 주장하는 신원이 실제로 맞는지 확인하는 절차이고, 인가는 인증된 사용자가 특정 자원이나 기능에 접근할 권한이 있는지 확인하는 절차이다. 예를 들어 아이디와 비밀번호로 로그인하는 것은 인증이고, 관리자 페이지 접근 허용 여부를 판단하는 것은 인가이다.

로그인 보안을 위해 HTTPS를 적용하고, 비밀번호는 사용자별 솔트를 적용한 해시값으로 저장해야 한다. 또한 MFA, 로그인 실패 횟수 제한, Rate Limiting, CAPTCHA, 유출 비밀번호 차단, 로그인 후 세션 재발급, 비정상 로그인 탐지와 로그 모니터링을 적용해야 한다.

IDOR는 사용자가 요청 파라미터의 객체 식별자를 조작하여 권한 없는 타인의 자원에 접근하는 접근통제 취약점이다. 대응 방안으로는 서버 측에서 매 요청마다 사용자 권한과 자원 소유자를 검증하고, 역할 기반 접근통제를 적용하며, 단순 순번 ID 노출을 줄이고 비정상 객체 ID 순차 접근을 로그로 모니터링해야 한다.

세션 보안을 위해 예측 불가능한 세션 ID를 사용하고, 로그인 성공 후 세션 ID를 재발급하여 세션 고정 공격을 방지해야 한다. 또한 HTTPS, HttpOnly·Secure·SameSite 쿠키 설정, 세션 타임아웃, 로그아웃 시 서버 측 세션 폐기, 중요 기능 재인증, 이상 접속 탐지를 적용해야 한다.

JWT는 JSON 형식의 클레임을 담고 서명을 통해 위변조 여부를 검증할 수 있는 토큰 기반 인증 방식이다. 보안 운영을 위해 서명 검증, 안전한 알고리즘 사용, 짧은 만료시간 설정, Payload에 민감정보 저장 금지, HTTPS 전송, 토큰 탈취 대비 폐기·재발급 정책, 권한 클레임 검증이 필요하다.

API 보안을 위해 모든 요청에 인증을 적용하고, 사용자가 요청한 자원에 접근할 권한이 있는지 서버 측에서 검증해야 한다. 또한 입력값 검증, 응답 데이터 최소화, Rate Limiting, 토큰 만료와 폐기 정책, Mass Assignment 방지, CORS 제한, 오류 메시지 노출 제한, API 호출 로그 기록을 적용해야 한다.

인증은 사용자의 신원을 확인하는 절차이고, 인가는 인증된 사용자가 특정 자원이나 기능에 접근할 권한이 있는지 확인하는 절차이다.

MFA는 지식, 소유, 생체 등 서로 다른 인증 요소를 2개 이상 결합하여 계정 탈취 위험을 줄이는 인증 방식이다.

비밀번호는 평문으로 저장하지 않고 사용자별 솔트를 적용한 해시값으로 저장해야 한다.

브루트포스 공격은 가능한 비밀번호를 무차별적으로 반복 대입하는 공격이고, 크리덴셜 스터핑은 유출된 계정 정보를 다른 서비스에 대입하는 공격이다.

세션 보안을 위해 예측 불가능한 세션 ID, 로그인 후 세션 재발급, HttpOnly·Secure·SameSite 쿠키, 세션 타임아웃, 로그아웃 시 세션 폐기를 적용해야 한다.

JWT는 JSON 형식의 클레임을 담고 서명으로 위변조 여부를 검증할 수 있는 토큰 기반 인증 방식이다.

JWT Payload는 쉽게 디코딩될 수 있으므로 민감정보를 저장하지 않아야 하며, 서버는 서명과 만료시간을 반드시 검증해야 한다.

IDOR는 요청 파라미터의 객체 식별자를 조작하여 권한 없는 타인의 자원에 접근하는 취약점이다.

IDOR 대응의 핵심은 서버 측에서 매 요청마다 사용자 권한과 자원 소유자를 검증하는 것이다.

API 보안을 위해 모든 요청에 인증과 인가를 적용하고, 입력값 검증, 응답 데이터 최소화, Rate Limiting, 토큰 관리, 로그 기록을 수행해야 한다.

Mass Assignment를 방지하려면 클라이언트가 보낸 모든 필드를 자동 반영하지 말고 허용된 필드만 명시적으로 반영해야 한다.

관리자 페이지는 MFA, 접근 IP 제한, 서버 측 권한 검증, 중요 작업 재인증, 작업 로그 기록으로 보호해야 한다.

1. 인증이란 무엇인가?
2. 인가란 무엇인가?
3. 인증과 인가의 차이를 쓰시오.
4. 인증 요소 3가지를 쓰시오.
5. MFA란 무엇인가?
6. MFA가 계정 탈취 방지에 도움이 되는 이유는 무엇인가?
7. 안전한 비밀번호 정책 항목 5가지를 쓰시오.
8. 비밀번호를 평문으로 저장하면 안 되는 이유는 무엇인가?
9. 솔트란 무엇이며 왜 필요한가?
10. 브루트포스 공격이란 무엇인가?
11. 크리덴셜 스터핑이란 무엇인가?
12. 로그인 보안 대책 6가지를 쓰시오.
13. 접근통제 취약점이란 무엇인가?
14. 수평 권한 상승과 수직 권한 상승의 차이를 쓰시오.
15. IDOR란 무엇인가?
16. IDOR 대응 방안 4가지를 쓰시오.
17. 관리자 페이지 보호 대책 5가지를 쓰시오.
18. 세션 고정 공격이란 무엇인가?
19. 세션 관리 보안 대책 6가지를 쓰시오.
20. JWT란 무엇인가?
21. JWT의 구성 요소 3가지를 쓰시오.
22. JWT 사용 시 보안상 주의사항 5가지를 쓰시오.
23. API 보안이 중요한 이유는 무엇인가?
24. API 보안 대책 8가지를 쓰시오.
25. Mass Assignment란 무엇인가?
26. 과도한 데이터 노출이 위험한 이유는 무엇인가?
27. API Rate Limiting이 필요한 이유는 무엇인가?
28. CORS 설정 시 주의할 점은 무엇인가?

29. 비밀번호를 가능한 조합으로 계속 대입하고 있다.
30. 다른 사이트에서 유출된 아이디와 비밀번호로 로그인 시도하고 있다.
31. 로그인 성공 후에도 기존 세션 ID가 그대로 유지된다.
32. URL의 userId 값을 바꾸자 다른 사용자의 정보가 조회되었다.
33. 일반 사용자가 관리자 API를 직접 호출해 성공했다.
34. 클라이언트가 role=admin 값을 보내자 서버가 그대로 반영했다.
35. API 응답에 화면에 필요 없는 passwordHash와 주민등록번호가 포함되었다.
36. Authorization Bearer 토큰이 만료시간 없이 장기간 유효하다.
37. JWT Payload에 주민등록번호와 비밀번호가 들어 있다.
38. API를 짧은 시간에 수천 번 호출하여 사용자 정보를 수집하고 있다.
39. 허용되지 않은 외부 도메인에서 인증정보 포함 API 요청이 가능하다.
40. 관리자 페이지가 외부 전체 IP에서 접근 가능하고 MFA가 없다.

41. 인증과 인가의 차이를 설명하시오.

42. 로그인 보안 대책을 설명하시오.

43. 세션 관리 보안 대책을 설명하시오.

44. IDOR 취약점의 개념과 대응 방안을 설명하시오.

45. JWT 사용 시 보안상 주의사항을 설명하시오.

46. API 보안 대책을 설명하시오.