API의 속성이 제한되는 현상 (CORS-safelisted response header, Access-Control-Expose-Headers)

API를 받았는데, API의 속성이 제한되는 현상이 일어났다.

하지만, 동료는 정상적으로 API 정보(속성들)가 전달된다한다.

무엇이 문제였을까?

 

결론부터 말하면, 백엔드에서 Header 설정을 하지 않았다.

좀 더 구체적으로 보자.

 

문제의 발생

몇 가지 조건이 겹쳤다.

1. 현재 우리는 local Proxy를 이용하여 가볍게 개발중이다.

2. 백엔드에서 cors 에러를 방지하기 위해서 'Access-Control-Allow-Origin: *' 설정을 하여서 예외처리 해두었다.

 

이 상황에서 나는 테스트 서버로 api 요청을 보내야했고, 이 과정에서 굳이 local Proxy를 사용할 필요가 없다 느껴서 서버 주소를 직접 입력하여서 보냈다.

 

그리고 아래 사진처럼 제한된 값이 도달했다. 하지만, 네트워크에는 원하는 정보들이 제대로 전송되었다. cors 및 기타 에러는 전혀 발생하지 않았다.. 근데 왜 안 보일까..?

보이는 게 너무 제한적인 Header, jwt 토큰을 주지 않는다.

이것 저것 잘 들어왔다는 네트워크 탭

문제의 원인 및 해결

CORS-safelisted response header 라는 것이 있다.

교차 자원(cross-origin)에서 온 자원들 중 client의 노출되어도 괜찮은 header 값들만 브라우저(Client)에 공개된다는 것이다. 그래서 아래 속성을 제외하고는 브라우저(Client)에서는 접근이 불가능하다.

• Cache-Control
• Content-Language
• Content-Length
• Content-Type
• Expires
• Last-Modified
• Pragma

위 값을 제외한 다른 값들을 접근하고 싶다면, 백엔드쪽에서는 Access-Control-Expose-Headers를 설정해주면, 브라우저에서 이제 접근이 가능해진다.

 

느낀 점

어느정도 네트워크와 백엔드에 대한 지식은 필수적이여야하는 것 같다...

에러가 났는데, 200 상태코드가 나오니 내 잘못인 줄 알고 코드를 하나하나 분해해서 디버깅했다. 하루를 통째로 디버깅을 해보고 나서야, 나는 잘못된 게 없다는 걸 알았고 다른 조건인 로컬 프록시는 이런 에러가 발생하지 않는 걸 알았다.

그 뒤에는 다시 왜 로컬프록시는 되는 지 하나하나 비교하고 찾아보느라 반나절을 사용했다. 덕분에 깔끔하게 속성 하나하나 조사하고, 에러 원인을 명확히 찾을 수 있었지만 개발을 이틀이나 할 수 없었다..

 

다음에는 그래도, 이거 설정해서 주세요. 라고 당당히 말할 수 있으니 좋은 기회라 생각하자

 

참고자료

CORS-safelisted response header mdn : https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_response_header