신입 첫 프로젝트에 백엔드 개발자로 투입되었을 때 어도비 API를 활용하게 되었다.

DB를 거치지 않는 API는 프론트 측에서 처리하는 것으로 방향을 잡고 개발을 하고 있었다.

개발이 중간쯤 진행되고 있었는데 프론트에서 Adobe 모든 API에서 CORS 에러가 발생한다고 보고했다.

원인을 알기 전에 다른 팀 두분께 해당 CORS 문제에 대해 물어본 적있었는데 모두 백엔드 프록시를 해결책으로 말씀해주셨다.

그래서 백서버에서 프록시를 만들어 adobe를 향한 모든 요청을 우회시켜야할 가능성도 상정해두었다.

나중에 나는 해당 CORS 에러의 문제가 원인이 프론트엔드측에서 발생한 것임을 알게되었고 백엔드에서 불필요한 프록시는 하지 않아도 되었다.

문제의 원인은 프론트 엔드 개발자가 axios로 보내는 모든 httpRequest에 특정한 해더가 자동 삽입된 채로 보내진다는 사실을 파악하지 못한 까닭이었다.

AdoebeAPI 엔드포인트로 요청을 보내면서 프론트엔드는 “X-AUTH-TOKEN”이라는 해더를 포함해서 보냈는데 예비API요청에 해당하는 Method:OPTION 인 Preflight 요청에서 Adobe측 응답으로 받은 “Access-Control-Allow-Headers” 해더의 값에 “X-AUTH-TOKEN”가 있지 않았고 웹 브라우저가 이를 감지해 본 HTTP 요청을 block 한 것이다. 부적절한 헤더가 포함되었다는 에러는 브라우저의 CORS policy의 하위 에러였고 프론트엔드가 CORS에러가 발생했다고 보고했기 때문에 난 AdobeAPI에서 “Acess-Controll-Allow-Origin”헤더를 “*“등으로 열어주지 않아서 생긴 문제라고 오해를 했다. 그러나 실제로 preflight 응답에서는 그것이 열려 있었다.

프론트엔드는 백엔드 요청을 보낼 때 편의성을 위해 JWT토큰을 담는 “X-AUTH-TOKEN”를 자동 삽입하게 설계한 듯 했다. 프론트는 이사실을 인지하지 못한 상태로 외부 API와 통신하려고 해서 생긴 문제였다. 그래서 프론트 측에서 잘못된 해더가 보내지지 않게 로직을 수정했고 케이스는 종료되었다.