배포된 백엔드 서버의 보안을 위해 CORS 설정을 동일 주소(Same-Site)만 가능하게 했다.
그렇게 설정 후 로컬(local) 프론트(next.js) 프로젝트를 빌드 해 봤다.
문제없이?! 배포된 백엔드 api를 이용해서 잘 빌드가 됐다. 너무나 잘 됐네???
???
왜 되지????😰
너 왜 빌드 됐니?
라는 문제가 그렇게 나에게 나타났다.
로컬 프론트 서버는 어떻게
동일 출처(Same-Site)만 허락하는 배포 서버 api를 이용해서
빌드할 수 있었을까?
SSG/SSR/ISR을 만들 수 있었을까?
https://www.example.com
https://www.example.com/api
http://localhost:3000
이렇게 주소를 설정해 CORS의 문제를 겼지 않고
동일 주소(Same-Site)의 이점을 가져간다고 하자.
import cors from "cors";
app.use(cors({
origin: 'https://www.example.com'
}));
CORS에 Method에 GET을 안 넣어서 그런가?
-> GET 넣음. 그래도 안됨.
실제 로컬 프론트 사이트를 열어 get 요청을 보내봄
-> 막힘
-> 어? GET 요청이 CORS로 막히잖아?
지겹게 읽었던 CORS의 정의
하지만 다시 상기시켜보자.
교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 브라우저가 자신의 출처가 아닌 다른 어떤 출처(도메인, 스킴 혹은 포트)로부터 자원을 로딩하는 것을 허용하도록 서버가 허가해주는 HTTP 헤더 기반 메커니즘입니다.
여기서 중요한 점은 브라우저가 이 행위를 한다는 것이다.
매일 브라우저 안에서 살았던 프론트
그래서 브라우저는 공기와 같은 것이라
사실 브라우저는 언제나 존재하는 것이었다. 당연하게
하지만 당연한가???
너무 자연스럽게 프론트와 백엔드만 생각했지만
사실
프론트 서버 ↔️ 브라우저 ↔️ 백엔드 서버
이러한 형태를 통해 매일 같이 사용하고 있었던 것이다.
사실 브라우저를 공기처럼 생각하는 것에는
React를 더 많이 사용하다 보니 프론트가 브라우저와 붙어서 언제나 함께 사용됐기 때문이다.
하지만 Next.js는 브라우저 없이 프론트가 움직이는 시간이 있다.
바로 SSG/SSR/ISR/서버 컴포넌트 를 만들 때,
Next.js는 클라이언트 없이 독립적으로 움직인다.
빌드 시
Next.js는
SSG/SSR/ISR을 만들 때
프론트 서버 ↔️ 백엔드 서버
이렇게 직접 백엔드와 소통을 하게 된다.
이유 :
1. CORS는 브라우저에 의해 일어난다.
2. Next.js 빌드 시에는 Next.js 서버가 백엔드와 직접 소통한다.
결론 :
CORS 에러 없이
Next.js 프론트 서버는
백엔드 서버에게
요청을 날리고 응답을 받을 수 있다!
그렇다.
그래서 보안을 위해서는
GET
api 는 안정성(데이터베이스 변화 없게) 있게 개발하는 것이 중요하구나.새삼 Next.js가 달리 느껴지고 브라우저의 존재에 대해 생각하게 되는 날이었다.
브라우저가 아닌 클라이언트는 또 얼마나 다른 세상(문제)가 있을까?
(짧지만, React Native 개발할 때 정말 이건 아니지 않나. 라는 생각이 많이 들었다...ㅎ)
'REST API는 HTTP 프로토콜을 기반으로 하므로, 다양한 클라이언트(웹 브라우저, 모바일 애플리케이션 등)에서 쉽게 사용할 수 있다.' 이 문장을 조금 더 이해하게 되는 날이었다.