쿠키·CORS·인증 경계

Framer로 배포 되어있는 곳과 Next API가 왜 서로 다른 origin 인지 부터 시작해, cookie·CORS·OAuth·proxy.ts가 그 경계를 넘기위해 각각 무엇을 하는지.

crossDomainCookieOptions()의 none+secure가 없으면 어디서 로그인이 깨지는지, 그리고 proxy.ts의 공개 경로 250개 버그가 왜 매 요청 getUser()를 태웠는지.

Origin의 정의와 Same-Origin Policy

Framer와 Next API, 그리고 실제로는 framer.app 도메인에서 서빙되는 코드 컴포넌트가 뒤섞여 동작하는 구조.
Framer -> Next.js 마이그레이션이 진행 중인 이유.

스크립트 파일을 어디서 받아왔는지는 그 코드의 오리진을 정하지 않는다.
오리진은 코드가 실행되는 문서가 정한다.

프로토콜·호스트·포트

해당 세 요소 중 하나만 달라도 왜 다른 오리진이 되는지, 그리고 maindomain.co.kr와 Framer가 제공하는 코드 컴포넌트 런타임은 왜 ㄷ같은 오리진이 아닐 수 있는지

오리진의 스킴(프로토콜) + 호스트 + 포트 세 가지로 정해지고, 셋이 모두 같아야 같은 오리진이다.

• https://ktmarket.co.kr와 https://www.ktmarket.co.kr -> 호스트가 달라서 다른 오리진이다.
• http://와 https:// -> 스킴이 달라서 다른 오리진이다. 포트토 기본값이 각각 80과 443으로 다르다.
• localhost:3000과 localhost:3001 -> 포트가 달라서 다른 오리진이다.

다음 날 쿠키를 공부할 때 중요해지는 개념 사이트이다. 사이트는 스킴과 등록 가능한 도메인으로 판단한다.
그래서 www와 apex 도메인은 다른 오리진이지만 같은 사이트이다.
반면 ktmarket.co.kr과 xxx.vercel.app은 다른 사이트이다.
오리진은 CORS 판단에 쓰이고, 사이트는 쿠키의 SameSite 판단에 쓰인다.

오리진을 결정하는 세 요소는 무엇이고, www.domain.co.kr와 ktmarket.co.kr은 같은 오리진인지.

Same-Origin Policy가 실제로 막는 것은 무엇인지

요청 자체를 막는건지, 응답을 읽는 것을 막는건지.

SOP가 기본적으로 막는 것은 응답을 JS가 읽는 것.
단순 요청은 서버까지 실제로 도착하고 서버도 처리한다.
브라우저는 응답을 받은 뒤 Access-Control-Allow-Origin이 없으면 JS에 넘겨주지 않을 뿐이다.

예외는 preflight이다.
Content-Type: application/json이나 Authorization 헤더를 붙이면 브라우저가 먼저 OPTIONS 요청을 보낸다.
여기서 서버가 허락하지 않으면 본 요청은 아예 전송 되지 않음.

고로 "CORS 에러가 났으니 서버에 아무 일도 안 일어났다"라고 단정지으면 안된다.
단순 POST라면 DB에 이미 insert가 되어있을 수도 있음.

<script src> 나 <img src>로 다른 오리진 자원을 불러오는 건 되는데 fetch로 읽으려면 왜 CORS가 필요한지.

차이는 사용과 읽기 embed

• <script src>: 브라우저가 실행만 해줄 뿐, 페이지의 JS가 그 파일의 소스 텍스트를 문자열로 읽을 수는 없음.
• <img src >: 화면에 그릴 수는 있다. 하지만 canvas에 올려 픽셀을 읽으려 하면 canvas가 오염되 어막힘
• fetch: 응답 본문을 JS 변수로 통째로 가져온다. 만약 이게 허용되면, 내가 연 악성 페이지가 내 쿠키를 실어 은행 API를 호출하고 응답을 읽어 갈 수 있따. 그래서 서버가 명시적으로 허락인 COSR 헤더를 보내야만 읽을 수 있음.

Framer 코드 컴포넌트가 브라우저에서 실행될 때 그 스크립트의 오리진은 domain.co.kr인지, framer.app인지

이게 쿠키 전송 여부에 어떤 영향을 주는지.

Framer 코드 컴포넌트의 JS 번들은 Framer CDN에서 내려온다. 하지만 그 코드가 https://domain.co.kr 페이지 안에서 실행되면 오리진은 domain.co.kr이다.
그 안에서 실행되는 fetch의 Origin 헤더도 https://domain.co.kr이 된다.

쿠키에 미치는 영향도 오리진보다는 사이트 기준으로 생각해야 한다.

• Next API가 api.domain.co.kr 처럼 같은 사이트에 있다면: domain.co.kr 페이지에서 보내는 요청은 cross-origin 이지만 same-site이다.
  이 경우 SameSite=Lax 쿠키도 credentials:'include'와 함꼐 전송된다.

추후 crossDomainCookieOptions()의 none+secure 문제로 이어진다.