- TL;DR : API 호출을 HTTP에서 HTTPS로 리디렉션하는 대신 실패를 표시할 것. HTTP를 완전 비활성화 하거나 명확한 HTTP 오류 응답을 반환하고 비암호화 연결로 전송된 API키를 취소할 것. 안타깝게도 현재 많은 유명 API 제공업체는 그렇게 하지 않음.
배경
- 웹 브라우저가 HTTP URL로 접속할 때, 서비스는 종종 해당 요청을 HTTPS 페이지로 리디렉션함.
- 초기 HTTP 트래픽은 암호화되지 않아, 네트워크 중간자(MITM) 공격에 취약함.
- HSTS(HTTP Strict Transport Security)와 같은 기술이 도입되어 보안이 강화됨.
간단한 오타의 위험성
- 작업 중 제3자 API와의 통합 과정에서 API 기본 URL을
https://대신http://로 잘못 입력함. - Node.js의
fetch가 조용히 HTTPS로 리디렉션을 따름. - API 키가 평문으로 전송되어 보안 위험이 발생할 수 있었음.
- 코드 리뷰 중 오류를 발견하여 문제를 해결함.
빠른 실패 원칙
- API가 HTTP 요청을 HTTPS로 리디렉션하면 오타를 쉽게 놓칠 수 있음.
- 빠른 실패 원칙을 따르는 것이 좋음: 암호화되지 않은 API 호출은 명확하게 실패해야 함.
- API 서버의 HTTP 인터페이스를 비활성화하거나, HTTP 요청에 대해 오류 메시지를 반환하는 것이 좋음.
다른 API의 사례
- 여러 유명 API가 HTTP 요청에 대해 403 오류 메시지를 반환하거나 HTTP 인터페이스를 비활성화함.
- 그러나 일부 API는 여전히 HTTP에서 HTTPS로 리디렉션함.
모범 사례의 필요성
- 사용자 지향 애플리케이션에서는 HTTP에서 HTTPS로 리디렉션이 일반적임.
- API의 경우, HTTP에서 HTTPS로 리디렉션하는 것이 오히려 해로울 수 있음.
- OWASP와 같은 보안 프로젝트에서 API에 대한 명확한 지침이 필요함.
결론
- API는 HTTP에서 HTTPS로 리디렉션하는 대신, 암호화되지 않은 요청을 명확하게 실패하게 해야 함.
- API 키가 암호화되지 않은 연결을 통해 전송되면 즉시 취소해야 함.
- API 보안 모범 사례를 업데이트하여 명확한 지침을 제공할 필요가 있음.
GN⁺의 의견
- 보안 강화 필요성: API 보안은 매우 중요하며, HTTP에서 HTTPS로의 리디렉션은 보안 취약점을 초래할 수 있음.
- 빠른 실패 원칙: 개발 초기 단계에서 오류를 발견하고 수정할 수 있도록 빠른 실패 원칙을 따르는 것이 중요함.
- 모범 사례 업데이트: OWASP와 같은 보안 프로젝트에서 API 보안에 대한 명확한 지침을 제공해야 함.
- 자동화된 키 취소: 암호화되지 않은 연결을 통해 전송된 API 키는 자동으로 취소되어야 함.
- 다른 API의 사례 참고: 다른 API의 보안 사례를 참고하여 자신의 API 보안을 강화할 필요가 있음.