귀하가 설정한 랜딩 페이지에서 외부 API에 대한 호출을 구현하기를 원하는 클라이언트가 있는 시나리오를 상상해 보십시오. 외부 API는 해당 계약을 통해 얻은 계약 및 API 키를 기반으로 작동합니다. 따라서 fetch()프런트엔드 호출 시 API 키를 노출해서는 안 됩니다 .
따라서 이제 중간 서버 역할을 하는 Docker 인스턴스를 구현하여 LP의 fetch()호출을 외부 API에 연결하여 모든 요청에 대해 다음과 같은 트래픽이 발생하도록 해야 합니다.
client --> Docker container --> API --> Docker container --> client
보안을 계속 엄격하게 유지하기 위해 이제 클라이언트에서 Docker 컨테이너로 들어오는 요청을 인증하는 최선의 접근 방식이 궁금합니다. 인증은 페이지 로드 시 클라이언트에 전달되는 CSRF 토큰을 통해 구현됩니다. 성공적인 초기 인증을 게시합니다.
랜딩 페이지에 로그인 시스템이 없고 HTTP/타사 쿠키가 아닌 쿠키에 의존할 수 없다는 점을 고려하여 배포된 랜딩 페이지의 도메인에서 시작되는 Docker 컨테이너로 요청이 들어오는 것을 허용하는 방법만 생각했습니다. 하지만 A) 이것이 가능한지( Acces-Control-Allow-OriginDocker 컨테이너의 구성을 생각했나요?) B) 이것이 안전한지는 모르겠습니다 . 특히 B)에 대해 궁금합니다. 리퍼러 헤더와 같은 것을 위조하는 것은 매우 쉽기 때문에 요청이 발생한 도메인 이름도 쉽게 위조될 수 있는지 궁금합니다.
내가 올바르게 이해했다면 헤더 를 통해 제공된 규칙은 Access-Control-Allow-Origin브라우저에서만 시행되며, 예를 들어 간단한 HTTP 클라이언트는 이를 우회하거나 무시할 수 있습니다. 옳은?
기본 인증도 생각했지만, 이 경우 js에 인증 토큰을 제공해야 하기 때문에 클라이언트 코드 내에서 아무것도 노출하지 않는 일종의 인증을 선호합니다.
Docker 컨테이너가 Apache에서 실행된다는 점을 감안할 때 이 사용 사례에 대한 가장 엄격한 솔루션은 다음을 통해 배포된 LP의 IP에 대한 액세스를 제한하는 것이라고 생각합니다.이것, 다음과 같은 것을 사용하여이것. 나는 이것이 오히려 인증에 비해 액세스 제한이라는 것을 알고 있습니다. 하지만 클라이언트에게 아무 것도 노출하지 않는 이 랜딩 페이지 시나리오에 대한 최상의 솔루션이라고 생각합니까?