[Cross-Origin Resource Sharing]
웹 브라우저가 서버와 다른 도메인에서 리소스를 요청할 때 적용되는 보안 정책이다. 동일 출처 정책이라고 하는데 간단히 말하면 같은 도메인끼리 데이터를 주고받아야 안전하다는 것이다.
// HTTP 헤더를 사용하여 허용할 도메인을 추가할 수 있다.
Access-Control-Allow-Origin: 도메인
CORS 에러라는 단어 자체를 고유 명사처럼 너무 많이 들어서 직접 경험해보고 싶었는데 이번 프로젝트를 진행하면서 원없이 경험할 수 있었다.
프록시를 사용하여 클라이언트에서 CORS 문제를 해결하는 것은 완전한 해결이 아니라 단지 우회일 뿐이다. 서버가 적절히 CORS 설정을 하지 않으면, 클라이언트는 자유롭게 요청을 시도할 수 있어 보안 문제가 발생할 수 있다. 리소스를 소유한 주체는 서버이므로, 요청에 대한 허용 여부와 접근 권한은 서버에서 명확히 관리하는 것이 좋다.
브라우저는 리소스를 얻기 위해 프리플라이트 요청을 보내 서버의 응답을 확인하고 실제 요청을 보낸다. 서버는 이 요청을 허용한다면 헤더에 필요한 값들을 담아 응답한다. 그리고 브라우저는 서버의 응답 헤더를 보고 허용되지 않으면 요청을 차단한다.
1. 클라이언트의 프리플라이트 요청: HTTP OPTIONS 사용
// 요청 헤더
OPTIONS /resource HTTP/1.1
Host: [호스트이름]:[포트번호]
Origin: 리소스 요청 도메인
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type // 실제 요청에서 사용하려는 헤더
2. 서버 응답
// 응답 헤더
HTTP/1.1 200 OK
Access-Control-Allow-Origin: 리소스 요청 도메인
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type // 허용 응답
Access-Control-Max-Age: 3600
3. 허용 시 클라이언트 Request
- 프리플라이트 요청에서 확인된 헤더가 포함된다.
POST /resource HTTP/1.1
Host: [호스트이름]:[포트번호]
Origin: 리소스 요청 도메인
Content-Type: application/json
// data
4. 서버 응답
HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: 리소스 요청 도메인
// data
요청 헤더에 담기는 Host 정보는 클라이언트가 요청하는 리소스가 위치한 서버의 도메인명과 포트 번호이다. 단일 서버 환경에서는 중요하지 않을 수 있지만, 여러 도메인을 처리하는 가상 호스팅 환경이나 분산 시스템에서는 요청이 올바른 서버로 라우팅 되는 데 필수적이다.
요청이나 작업을 중간에서 가로채고 제어하는 것을 말한다. 웹서비스를 만들면서 흔히 접할 수 있는 프록시는 네트워크 프록시로 볼 수 있다.
Vite로 세팅한 프로젝트에서 CORS 에러를 해결하기 위해 프록시 설정을 했었는데 이는 우회하는 방법이다. 결국 서버에서 origin 설정을 추가해 주어 해결할 수 있었는데 에러 해결을 위해 막 쓸 때는 어차피 서버가 해줄 거면 프록시 설정을 왜 한 거지?라는 의문이 들었다.
클라이언트의 네트워크 요청을 가로채어 다른 서버로 전달하거나 중계한다. 2가지의 방식이 있는데 가로채는 역할로 비슷해 보이지만, 주요 차이점은 아래와 같다.
`클라이언트 중심`, 클라이언트의 요청을 제한하거나 제어하기 위해 사용된다.
`서버 중심`, 서버 성능 최적화와 보안을 위해 사용된다.(Nginx, Apache HTTP Server, API Gateway)
Vite를 사용하는 프로젝트는 프록시 설정이 가능하다. 클라이언트 측에서 설정하여 포워드 프록시 같지만, 일부 기능을 구현한 개발 환경용 도구라고 할 수 있다. 한 번 더 짚고 넘어가자.
Vite의 프록시는 개발 환경에서만 실행된다. 이때는 서버의 허용 없이도 CORS 에러를 피할 수 있다.
rewrite: (path) => path.replace(/^\/api/, '')백엔드 API에는 없지만, 클라이언트에서 요청하는 API 함수에는 api 접두사를 붙여서 구분한 다음 프록시 서버는 api를 떼어내어 요청한다. 만일 API 자체에 api 가 붙는다면 필요하지 않다.
/api/users로 요청 → 백엔드 서버(http://localhost:8080/users)로 전달
// rewrite 필요 없음
/api/users로 요청 → 백엔드 서버(http://localhost:8080/api/users)로 전달
Vite는 Node.js 기반으로 개발 서버는 node-http-proxy를 사용하여 프록시를 지원한다. 만일 별도 빌드툴을 사용하지 않는다면 프록시 전용 서버를 구축해서 이를 해결해야 한다.
프로젝트에서 구글 소셜 로그인을 적용했다. 서버로부터 `OAuth Page URL`을 받아서 redirect 하는데 이때 서버의 port 번호는 8080, 클라이언트는 3000이었다. 처음에는 `vite.config.js` 설정을 이용해서 port 번호를 8080으로 맞추었다가 서버에서 port 3000을 허용하는 방식으로 변경했다.
Access to XMLHttpRequest at '백엔드 서버 URL' from origin '요청 URL' has been blocked by CORS policy
: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.세션 기반 인증을 하고 있어 쿠키를 주고받게 되는데 요청에 쿠키가 포함되지 않아 발생한 에러이다.
withCredentials: true
해당 옵션을 주어 요청 헤더에 쿠키가 포함되도록 한다. 이 옵션은 axios나 fetch API 등을 이용해 HTTP 요청을 보낼 때, 요청에 쿠키나 인증 헤더 등을 포함할지 여부를 설정하는 옵션이다. 브라우저는 기본적으로 이를 포함하지 않기 때문에 설정하지 않으면 쿠키를 서버로 전달하지 않는다.
AWS에 프로젝트를 배포하기 전, 현재 프론트를 vercel에 배포하였는데 이때 다시 CORS 에러를 만나게 되었다. 배포 후에도 프론트와 서버의 도메인이 다른데 지금까지 했던 설정은 개발 환경에만 적용되면서 CORS 에러가 다시 발생하게 된다.
Vercel에서 제공하는 도메인은 기본적으로 HTTPS로 제공되어 HTTP 요청이 들어오면 자동으로 HTTPS로 리다이렉트 된다.
`vercel.json` 파일의 설정에서 destination 경로에 https를 설정하는 방법을 썼지만, 해당 에러가 해결되지 않아 백엔드와 의논하여 ngrok 설정을 통해 https 도메인을 설정했다.
📌 ngrok 이란?
개발 환경에서 외부 네트워크가 백엔드 로컬 환경으로 접속할 수 있게 해주는 터널링 서비스이다. 임시로 유효한 퍼블릭 URL을 생성하여 이 URL로 들어오는 모든 요청을 로컬 서버로 전달한다. 곧, ngrok 서비스도 리버스 프록시를 통해 우회한다.
ngrok을 이용해 해당 에러를 해결했지만, 나는 SSL 인증서를 발급받은 적이 없는데 어떻게 https를 쓸 수 있을까? 그 이유는 ngrok에서 이미 SSL/TLS 인증서를 적용하고 관리하기 때문이다. 클라이언트가 ngrok URL로 HTTPS 요청을 보내면, ngrok 서버는 이를 처리한 뒤 로컬 HTTP 서버로 전달한다.
ngrok은 클라이언트와 로컬 서버 사이에서 리버스 프록시 역할을 하며, 요청과 응답을 중계한다. 이 때문에 로컬 서버는 HTTPS 설정 없이 외부 HTTPS 요청을 처리할 수 있다.
sameSite는 쿠키가 전송되는 방식을 결정하는 옵션이다.
JSESSION을 처음 로그인 시에만 받아오고 이후 휘발 되어 SameSite에 경고가 뜬다.
SameSite 설정을 none으로 하여 쿠키가 전송되도록 한다.
//vite.config.js
server: {
proxy: {
'/api': {
target: '백엔드 서버 URL',
changeOrigin: true,
rewrite: (path) => path.replace(/^\\/api/, ''),
},
},
},
처음 만난 CORS 에러에 후다닥 config파일을 수정해서 proxy 설정을 했다. api가 포함된 API 요청은 빈 문자열로 변경하여 우회하도록 한다. 이때 `vite.config.js`를 프로젝트 레포지토리에 올렸는데 서버 URL이 그대로 노출되는 문제가 생겼다. 헐레벌떡 해당 파일을 삭제해 보려고 처음 보는 깃 명령어도 써보며 커밋 내역을 삭제하려고 해 보았다.
// 파일 제거
1. git filter-branch --force --index-filter \\ "git rm --cached --ignore-unmatch 경로/삭제할파일명" \\ --prune-empty --tag-name-filter cat -- --all
2. git reflog expire --expire=now --all && git gc --prune=now --aggressive
// 특정 문자열 제거
git filter-branch --force --tree-filter \\ 'find . -name "vite.config.ts" -exec sed -i "" "s|지우려는_문자||g" {} +' -- --all
잘 삭제되는가 싶었는데 나중에 보니 PR 기록의 커밋 내역에는 그대로 남게 되어 소용이 없었다. 결국 백엔드와 협의하여 서버 URL을 변경하는 것으로 해결하였다. 하지만 어쨌든 서버 URL이 있어야 프록시 되기 때문에 이 부분을 감추기 위해 다른 설정을 추가했다.
export default defineConfig(({ mode }) => {
const env = loadEnv(mode, process.cwd());
...
}
이후 vite.config.js 파일 내에서는 `import.meta.env`를 사용할 수 없어서 Vite에서 제공하는 방법을 사용했다.
CORS 에러에 대해 마침내 제대로 알아볼 기회가 왔다. 혼자 진행했던 프로젝트에서는 접할 일이 적어 어렴풋이 알고 있었는데, 팀 프로젝트에서 백엔드와 직접 API 통신을 하게 되면서 비로소 경험할 수 있었다. 흔한 에러라 해결 자체는 어렵지 않았지만, 에러가 발생하는 원리와 해결 과정의 메커니즘을 이해하는 데 집중할 수 있었다. 무엇이든 완전히 모르는 것보다 어설프게 알고 있을 때가 더 공부하기 어렵다는 생각이 든다.
| 좋은 UX를 위한 보이지 않는 에러 다루기 (0) | 2024.12.16 |
|---|---|
| 낙관적 업데이트, 좋아요 말고 어디에 쓸까? (1) | 2024.12.08 |
| 나만 빼고 다 하는 오픈소스 기여 맛보기 (2) | 2024.09.08 |
| 얕은 지식으로 시작하는 React 프로젝트 세팅 (0) | 2024.08.08 |
| Firebase로 실시간 데이터 동기화하기 (0) | 2024.07.14 |