본문 바로가기
개발자도구

403 vs 401 에러 코드

by 로맨틱스터디 2025. 12. 1.
728x90
반응형

**403 에러(HTTP 403 Forbidden)**는 서버가 요청을 이해했지만, "접근 권한이 없어서" 요청을 거부할 때 발생하는 오류야.

즉,
👉 “너의 요청은 알아들었지만, 이 리소스에는 들어갈 수 없어.”


✅ 403 에러의 의미

  • 요청 자체는 정상적임 (문법적으로 문제 없음)
  • 서버도 요청을 이해함
  • 하지만 서버가 접근을 허용하지 않음

✅ 403이 발생하는 주요 원인

1. 접근 권한 없음 (권한 문제)

  • 로그인을 안 했는데 로그인 필요할 때
  • 특정 사용자/역할만 볼 수 있게 제한된 페이지
  • IP 제한

Q. 로그인 관련 문제는 401 아닌가?

더보기

이 부분이 401과 403의 가장 헷갈리는 포인트인데, 정확하게 짚어보면 다음과 같아.


✅ 기본 원칙

로그인이 필요한데 로그인을 안 한 상태라면 → 원칙적으로는 401 Unauthorized가 맞아.

  • 서버가 “인증이 필요합니다”라고 말하는 상황 → 401
  • 서버가 “로그인해도 너는 이 리소스를 볼 수 없어” → 403

✅ 그럼 왜 때때로 “로그인 안 했을 때 403이 뜨기도 할까?”

이게 바로 현실 서비스에서 헷갈리는 이유인데,

실제 서비스 설정 또는 보안 정책 때문에 401 대신 403을 반환하는 경우가 많기 때문이야.

1) 보안 정책으로 일부러 403을 사용

일부 서비스는 “이 리소스가 인증이 필요한지 여부조차 노출하고 싶지 않음”.
그래서 인증되지 않은 요청도 그냥 모두 403 처리.

→ 공격자에게 정보를 주지 않기 위한 보안 전략.

2) 서버 설정(Nginx, Apache)이 디렉토리 접근을 그냥 403으로 막음

인증과 관계없이, 여긴 그냥 접근 금지!”
이런 식으로 설정되어 있어서 403이 나옴.

3) 인증 체크 전에 권한 체크가 먼저 걸릴 때

개발자가 middleware나 filter를 다음과 같이 만들어놓았을 수도 있음:

if (!권한있음) return 403;
if (!로그인됨) return 401;

이러면 로그인 여부를 체크하기도 전에 403이 나와버림.

4) API 서버는 401 대신 403을 사용하는 경우도 많다

클라이언트 측에서 401이 뜨면 자동 로그아웃 처리를 하거나 토큰 재발급 요청을 보내기 때문에,
이를 피하기 위해 아예 403을 쓰는 경우가 있음.


🔍 결론

원칙적인 의미

상태 의미
401 Unauthorized 인증 필요함 (로그인 안 함 / 토큰 없음 / 토큰 만료)
403 Forbidden 인증은 했지만 권한이 없음

현실에서는

  • 보안 정책
  • 서버 설정
  • 프레임워크 기본값
  • 개발자 구현 방식
    때문에 로그인 안 했을 때도 403이 뜰 수 있다.

원하면

  • 401/403을 구분하는 REST API 설계 모범 사례
  • 실제 nginx/apach 설정 예
  • GitBook 같은 문서 서비스에서 어떻게 처리하는지
    도 더 알려줄게!

Q. 토큰은 로그인/인증에만 쓰이는가?

더보기

아니야!
토큰(Token)은 로그인과 인증에 쓰이는 경우가 가장 유명하지만, 그 외에도 다양한 용도로 사용돼.

 

정리해서 설명해줄게!


✅ 1) 로그인 / 인증(Authentication) 관련 토큰

가장 흔한 용도.

  • JWT(액세스 토큰 / 리프레시 토큰)
  • OAuth 토큰(Google, Kakao 로그인)
  • Session Token
  • API Token

👉 “누구인지 확인하기 위해” 사용됨.


✅ 2) 인가(Authorization) 관련 토큰

인증(로그인) 이후,
“이 유저가 어떤 권한을 갖는지” 판별할 때 쓰이기도 해.

 

예)

  • admin 권한이 있는지
  • 특정 리소스 접근 가능 여부
  • 특정 조직 소속 여부

JWT payload 안에 role 이나 scope 로 들어가는 정보들이 여기에 해당.


✅ 3) CSRF Token (보안 토큰)

로그인과 무관하게 보안 공격(CSRF) 방지를 위해 사용.

👉 사용자가 “의도한 요청인지” 확인
👉 폼 전송 시 서버에서 생성한 토큰을 보내야 함

이건 인증/로그인과는 완전히 별개!


✅ 4) API 호출용 토큰 (API Key, Service Token)

로그인 없이도 서비스끼리 통신할 때 쓰는 토큰.

 

예)

  • 서버 간 통신(Server-to-server)
  • OpenAI API Key
  • AWS Access Token
  • Slack Bot Token

👉 “시스템/앱이 누구인지” 인증하는 것 (사용자가 아님)


✅ 5) 결제 / 금융 토큰

  • 카드 토큰 (실제 카드번호 대신 쓰는 임시 식별자)
  • 결제 세션 토큰

👉 민감 정보 대신 “토큰”을 사용해 보안을 높임.


✅ 6) 트래킹/분석 관련 토큰

  • Google Analytics Client ID
  • 광고 추적 토큰
  • 푸시 알림 토큰(Device Token)

👉 사용자를 추적하거나 기기를 식별하기 위한 토큰
(로그인과 무관)


🔍 결론

토큰은 **“값(정보)을 안전하게 전달하기 위한 임시 식별자”**이고
로그인/인증에만 쓰이는 게 아니다.

✔ 로그인 O → 인증/인가 토큰
✔ 로그인 X → API 키, CSRF 토큰, 기기 토큰, 결제 토큰, 추적 토큰 등 다양함


토큰 종류별 차이(예: JWT vs API Key vs Session Token)도 비교해줄까?


 

🔥 CSRF(Cross-Site Request Forgery)란?

사용자가 의도하지 않은 요청을,
악성 사이트가 사용자의 계정 권한을 이용해서
서버에 보내는 공격이야.

 

즉,

로그인된 사용자의 쿠키를 악용몰래 요청을 보내는 공격”

이라고 보면 됨.


🧨 예시로 이해하기 (가장 쉬움)

1) 너가 이미 A사이트에 로그인

(쿠키에 세션이 저장된 상태)

2) 공격자가 만든 악성 사이트 B에 접속함

(겉보기엔 그냥 게시글, 이미지 등 정상적인 페이지처럼 생김)

3) 페이지 안에 이런 요청이 숨어 있음:

4) 브라우저는 알아서 쿠키를 붙여서 A사이트로 요청 보냄

→ 브라우저는 "쿠키가 A사이트의 것이니까 붙여야지" 하고 자동으로 세션 쿠키를 포함해서 요청함.

5) 서버는

"로그인된 사용자가 요청했네?"
라고 착각하고 실제로 동작함.

 

💥 그래서 원하지 않는 계정 변경/삭제/구매 등이 자동으로 이루어질 수 있음.


🔒 왜 이런 문제가 생길까?

브라우저는 같은 도메인의 쿠키를 자동으로 요청에 넣기 때문.

사용자가 요청했는지, 공격자가 요청했는지 서버는 알 수가 없음.


🛡 CSRF 방어 방법

CSRF는 오래된 공격이지만 지금도 반드시 막아야 하는 공격이며, 대표적인 방어 방식은:

✔ 1. CSRF 토큰 사용 (가장 유명)

  • 서버가 폼 렌더링할 때 임의의 토큰을 함께 보냄
  • 요청할 때 반드시 그 토큰을 포함해야
  • 공격 사이트는 이 토큰을 알 수 없음

즉,
👉 “진짜 사용자가 요청한 것인지” 확인하는 과정

✔ 2. SameSite 쿠키 옵션 설정

Set-Cookie: ...; SameSite=Lax
서드파티 사이트에서 쿠키를 자동으로 보내지 못하게 하는 방법.

✔ 3. Referer / Origin 체크

요청이 실제 본인 사이트에서 보낸 것인지 확인.

✔ 4. 중요한 요청은 GET 금지

계정 삭제 / 구매 / 설정 변경은 반드시 POST로 처리하도록 함.


📌 정리

CSRF = 악성 사이트가 사용자의 로그인 상태를 이용해 몰래 요청을 보내는 공격

 

방어는:

  • CSRF 토큰
  • SameSite 쿠키
  • Origin 체크 등으로 가능

원하면

  • CSRF vs XSS 차이
  • CSRF 공격 구조 그림
  • 사례별 코드 예시
    도 설명해줄게!

2. 서버 설정에서 특정 요청 차단

  • .htaccess나 Nginx 설정에서 디렉토리 접근 제한
  • 특정 파일 확장자 차단
  • CORS, 보안 설정

3. 디렉토리 listing 금지

웹 서버는 어떤 폴더에 index 파일이 없으면 기본적으로 폴더 내용을 리스트업하도록 할 수 있음.
하지만 보안 때문에 이를 차단해놓으면:

403 Forbidden

이렇게 표시됨.

 

예:
https://example.com/uploads/ 에 index.html 이 없고 디렉토리 listing도 금지된 경우.

4. 인증은 되었지만 권한이 부족한 경우

  • 로그인은 했지만 접근 가능한 레벨이 아닐 때
  • 회사 내부 시스템 등에서 발생

✅ 401 vs 403 차이

오류 의미
401 Unauthorized 인증(로그인)이 필요
403 Forbidden 인증을 했어도 권한이 없음 (또는 아예 허용하지 않음)

간단 요약

403 = “접근할 수 있는 권한이 없습니다.”

원인: 권한, IP 제한, 서버 설정, 디렉토리 listing 차단, 권한 부족 등.


필요하면

  • 어떤 상황에서 403이 뜨는지
  • 네가 만난 403의 원인 추정
  • 해결 방법
    도 알려줄게!
728x90
반응형