HTTP 400 Bad Request: 의미와 해결 방법

이 오류의 의미와 확인 방법

• 브라우저, API 클라이언트, 업타임 모니터, 웹훅 발신자 또는 기타 HTTP 클라이언트에 400 Bad Request가 표시됩니다.
• 특정 URL, HTTP 메서드, 쿼리 문자열, 요청 본문, 헤더 집합 또는 클라이언트에서만 응답이 나타날 수 있습니다.
• 엔드포인트가 HTTP 응답을 반환했으므로 DNS가 해석되고 TLS가 완료될 수 있습니다.
• 응답 본문에는 일반적인 오류 페이지가 표시되거나, 응답을 생성한 구성 요소에 따라 더 구체적인 유효성 검사 메시지가 표시될 수 있습니다.
• 응답 헤더에서 캐시 상태, 프록시 또는 CDN 정보, 인증 컨텍스트, 리디렉션 또는 요청 식별자를 확인할 수 있습니다.
• 배포 또는 라우팅, 유효성 검사, 프록시, 보안 규칙 변경 후 이전에 정상 작동하던 요청이 400을 반환하기 시작할 수 있습니다.

가능성이 높은 순서의 주요 원인

1. 형식이 잘못되었거나 유효하지 않은 요청 세부 정보: URL, 쿼리 문자열, 헤더, 쿠키, 메서드 또는 요청 본문이 엔드포인트가 요구하는 형식에 맞지 않을 수 있습니다.
2. 애플리케이션 유효성 검사 또는 라우팅 규칙: 애플리케이션이 누락되었거나 형식이 잘못되었거나 지원되지 않거나 서로 일치하지 않는 매개변수를 거부할 수 있습니다. 또는 요청이 해당 메서드를 허용하지 않는 라우트로 전송되었을 수 있습니다.
3. 웹 서버, 리버스 프록시, CDN 또는 WAF 처리: 파싱, 라우팅, 필터링 또는 정책 규칙 때문에 중간 구성 요소가 요청이 애플리케이션에 도달하기 전에 거부할 수 있습니다.
4. 요청 크기 또는 형식 제한: 본문, 헤더 집합, URL, 쿠키 모음 또는 업로드 값이 환경별 제한을 초과했거나 지원되지 않는 형식을 사용할 수 있습니다.
5. 인증 또는 세션 관련 요청 상태: 애플리케이션이 잘못된 토큰, 형식이 잘못된 세션 데이터 또는 예상 상태와 연결할 수 없는 요청에 대해 400을 사용할 수 있습니다. 관련 접근 문제에 401 또는 403을 사용하는 시스템도 있으므로 해당 로그에서 동작을 확인하세요.
6. 최근 구성 또는 배포 변경: 라우트, 유효성 검사 로직, 인증, 캐싱, 프록시, CDN 또는 보안 설정이 변경되면 이전과 비슷한 요청의 처리 방식이 달라질 수 있습니다.

해결 방법

방문자 또는 API 사용자라면

1. 정확한 URL을 한 번 다시 시도하고 오탈자, 의도하지 않은 공백, 잘린 쿼리 매개변수 또는 오래된 북마크가 없는지 확인하세요.
2. 요청에 계정이 필요하다면 사이트의 일반적인 절차로 로그인한 후 다시 시도하세요. 지원 요청에 비밀번호, 쿠키 또는 토큰을 붙여 넣지 마세요.
3. API 클라이언트를 사용한다면 HTTP 메서드, 필수 매개변수, 헤더, 콘텐츠 유형 및 요청 본문을 엔드포인트의 문서화된 요구 사항과 비교하세요.
4. 브라우저 요청이 실패했다면 계속 새로 고침하지 말고 동일한 작업을 한 번 시도해 보세요. 반복 요청은 부하를 늘리거나 속도 제한에 영향을 줄 수 있습니다.
5. URL 또는 엔드포인트, 메서드, 대략적인 시간, 응답 상태 및 응답에 표시된 요청 ID를 기록하세요. 사이트 운영자에게 공유할 때는 민감한 정보를 제거하세요.
6. 오류가 한 가지 작업에만 영향을 준다면 해당 작업과 기대한 동작을 함께 신고하세요. 관련 없는 여러 페이지에서 실패한다면 모든 실패의 원인이 같다고 가정하지 말고 더 넓은 영향 범위를 알려주세요.

사이트를 소유하거나 개발한다면

1. 최소 재현 사례를 확보하세요. HTTP 메서드, 민감한 값을 제거한 전체 URL, 상태, 응답 헤더, 관련 요청 헤더, 콘텐츠 유형 및 안전하게 최소화한 요청 본문을 기록하세요. 400이 리디렉션 후의 중간 응답이 아니라 최종 응답인지 확인하세요.
2. 정상 요청과 실패 요청을 비교하세요. 라우트, 메서드, 쿼리 매개변수, 본문 형식, 콘텐츠 유형, 쿠키, 인증 상태, 클라이언트 및 페이로드 크기를 확인하세요. 한 번에 하나의 관련 변수만 변경하세요.
3. 응답한 계층을 식별하세요. 응답 헤더, 본문 문구, 요청 ID 및 타임스탬프를 사용해 애플리케이션, 웹 서버, 리버스 프록시, CDN 또는 WAF 중 어디에서 응답을 생성했는지 확인하세요. 헤더 이름과 값은 환경에 따라 다르므로 확정적인 증거가 아닌 단서로 취급하세요.
4. 해당 로그를 확인하세요. 동일한 타임스탬프, 라우트, 메서드 및 요청 식별자를 사용해 식별한 계층과 인접 구성 요소를 검색하세요. 파서 오류, 유효성 검사 실패, 거부된 메서드, 제한 초과, 라우팅 불일치 또는 보안 규칙 일치 여부를 살펴보세요.
5. 최근 변경 사항을 검토하세요. 라우팅, 요청 파싱, 인증, 캐싱, 프록시 전달, CDN 동작 및 WAF 규칙에 영향을 주는 배포와 구성 변경을 비교하세요. 실패한 요청이 해당 라우트에서 허용되어야 하는 요청인지 확인하세요.
6. 가장 제한적인 안전한 수정만 적용하세요. 요청 계약 또는 유효한 트래픽을 거부하는 특정 라우트나 규칙을 수정하세요. 권한과 테스트 없이 광범위한 보안, 권한, 크기 제한 또는 프록시 변경을 적용하지 마세요.
7. 다시 테스트하고 주변 동작을 확인하세요. 원래 요청을 반복한 다음 의도한 메서드, 대표적인 잘못된 요청 및 관련 라우트를 테스트하세요. 수정으로 인해 잘못된 요청이 의도치 않게 성공하거나 리디렉션, 인증, 캐싱 또는 보안 제어가 손상되지 않는지 확인하세요.
8. 유용한 증거를 보존하세요. 일반적인 보존 및 개인정보 보호 관행에 따라 민감한 정보가 제거된 요청 세부 정보, 타임스탬프, 관련 헤더 및 로그를 보관하세요.

예방 및 해결 확인 방법

• 중요한 라우트에서 허용되는 메서드, 매개변수, 콘텐츠 유형, 인증 요구 사항 및 요청 크기 제한을 정의하고 문서화하세요.
• 요청을 일관되게 검증하고, 적절한 경우 유용하면서도 민감하지 않은 오류 메시지를 반환하세요.
• 라우팅, 프록시, CDN, 인증, 캐싱 및 WAF 구성을 변경 관리 대상으로 유지하세요.
• 애플리케이션 또는 인프라를 릴리스한 후 대표적인 정상 요청과 잘못된 요청을 테스트하세요.
• 라우트, 메서드, 클라이언트 및 배포별 400 발생률을 모니터링하여 국소적인 회귀와 광범위한 변경을 구분하세요.
• 응답과 응답을 생성한 구성 요소를 연관 지을 수 있도록 요청 식별자와 관련 로그를 충분한 기간 동안 보존하세요.
• 로그와 지원 증거에서 비밀번호, 쿠키, 인증 값, 개인정보 및 API 비밀 값을 삭제하거나 마스킹하세요.

자주 묻는 질문