HTTP 4xx·5xx 오류 처리: 상태 코드를 유지하며 상세 정보 숨기기

HTTP 오류 처리에서는 적절한 상태 코드를 유지하면서 스택 트레이스·SQL·내부 경로 같은 상세 정보를 숨깁니다. 오류를 모두 200으로 바꾸거나 홈페이지로 리디렉션하는 것이 일반적인 보안 해법은 아닙니다. 사용자 안내와 운영자 진단 정보를 분리하는 것이 핵심입니다.

4xx·5xx와 자주 보는 코드

코드	의미	확인할 경계
400	잘못된 요청	입력 형식·요청 구문
401	유효한 인증 정보가 필요함	인증 방식과 WWW-Authenticate 등 프로토콜 요구사항
403	서버가 요청 처리를 거부함	접근 정책·권한
404	현재 표현을 찾지 못했거나 존재를 공개하지 않음	실제 리소스와 공개 정책
500	예상하지 못한 서버 오류	애플리케이션 로그
502	게이트웨이가 업스트림에서 잘못된 응답을 받음	프록시·업스트림 연결
503	일시적으로 서비스할 수 없음	과부하·점검 등 서버 상태

4xx라고 항상 사용자가 잘못한 것은 아닙니다. 잘못 배포한 경로나 서버의 접근 정책 때문에 발생할 수도 있습니다. 5xx는 브라우저에서도 관찰할 수 있으며 발생 위치가 원본 서버인지 프록시인지 나눠 조사합니다.

공개 응답과 내부 로그를 나누는 예

HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{"message":"요청을 처리하지 못했습니다.","requestId":"example-123"}

이는 가상 응답 예제입니다. 운영 로그에는 같은 요청 ID로 예외와 필요한 진단 맥락을 남기되 비밀번호·토큰·불필요한 개인정보는 기록하지 않습니다. 사용자에게는 요청 ID로 문의할 수 있게 안내합니다.

예쁜 오류 화면도 HTTP 상태는 확인해야 합니다

curl --silent --show-error --dump-header - --output /dev/null   https://service.example.com/missing-page

자신이 관리하는 주소로 바꿔 GET 응답을 확인합니다. HEAD와 GET을 다르게 처리하는 서비스가 있어 이 예제는 GET을 사용합니다. 첫 응답의 상태와 Location을 먼저 보고 필요한 경우 이동 결과도 따로 검사하세요. 오류 안내 본문이 보이더라도 HTTP 200이면 클라이언트·모니터·검색 엔진이 다르게 해석할 수 있습니다.

Cloaking이라는 표현의 혼동

과거 글의 Error Response Cloaking은 상세 오류를 감추는 의미로 사용한 표현입니다. 검색 엔진과 일반 사용자에게 다른 콘텐츠를 제공하는 SEO의 Cloaking과는 구분해야 합니다. 제품별 기능 이름보다 “상태 코드·헤더·공개 본문에서 무엇을 바꾸는가”로 정의하는 편이 명확합니다. 리소스 존재를 감추기 위해 403 대신 404를 선택하는 정책은 가능하지만 인증·인가 검증을 대신하지 않습니다.