** 📌 5-1단계: CORS(Cross-Origin Resource Sharing) 완전정복**

Ajax 요청을 보낼 때 갑자기 “CORS 오류”가 뜨나요?

👉 이건 보안 정책 때문이에요! 왜 그런지, 어떻게 해결하는지 기초부터 심화까지 설명드릴게요.

---

✅ 1. CORS란?

📖 정의

❗CORS(Cross-Origin Resource Sharing)는

브라우저에서 다른 출처(origin)의 서버에 Ajax 요청을 보낼 수 있게 허용하는 방법입니다.

---

🧠 “출처(origin)”란?

항목	같은 출처인가?
http://abc.com → http://abc.com	✅ (같음)
http://abc.com → https://abc.com	❌ (프로토콜 다름)
http://abc.com → http://def.com	❌ (도메인 다름)
http://abc.com → http://abc.com:3000	❌ (포트 다름)

📦 출처(origin) = 프로토콜 + 도메인 + 포트가 모두 같아야 함

---

✅ 2. 왜 이런 제한이 있을까?

보안을 위해서예요! 😨

예시

• 당신이 abc.com에 로그인한 상태에서
• 누군가 evil.com에서 몰래 Ajax로 abc.com의 개인정보를 훔치면 안 되겠죠?

👉 그래서 브라우저는 다른 출처의 Ajax 요청을 원칙적으로 막아요

---

✅ 3. 그럼 왜 우리는 API를 사용할 수 있는 걸까?

바로 CORS 덕분이에요!

서버가 “이 요청은 괜찮아~”라고 허용하면, 브라우저도 허락합니다.

---

✅ 4. 핵심 응답 헤더: Access-Control-Allow-Origin

Access-Control-Allow-Origin: *

📌 의미

✅ “어디서 왔든 다 허용”

→ 모든 사이트에서 Ajax 가능

---

💡 더 안전한 설정 예시

Access-Control-Allow-Origin: https://yourfrontend.com

→ 오직 이 사이트에서만 Ajax 허용

---

✅ 5. Preflight 요청이란?

❗ 실제 Ajax 요청 전에 브라우저가 허락받기 위해 보내는 사전 확인 요청

---

📦 언제 발생하나요?

조건	Preflight 발생
POST 요청이면서, Content-Type이 application/json	✅ YES
PUT, DELETE 요청	✅ YES
요청 헤더에 Authorization, X-Custom-Header 등 커스텀 헤더가 있음	✅ YES

👉 이 경우, 브라우저가 먼저 OPTIONS 요청을 보냅니다.

---

📦 Preflight 요청 예시

OPTIONS /api/user
Origin: https://frontend.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type

→ 서버는 이렇게 응답해야 합니다:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://frontend.com
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type

✅ 이걸 보고 브라우저가 “좋아, 진짜 요청 보낼게!”라고 합니다.

---

✅ 6. 정리된 요청 흐름 (도식화)

[브라우저]
 ↓ ① OPTIONS (Preflight)
[서버] → 응답 OK
 ↓ ② 실제 Ajax 요청 (POST/GET 등)
[서버] → 응답 OK + Access-Control-Allow-Origin

---

✅ 7. 실무 CORS 설정 예 (서버 코드)

Node.js Express

app.use((req, res, next) => {
  res.header("Access-Control-Allow-Origin", "https://yourfrontend.com");
  res.header("Access-Control-Allow-Methods", "GET,POST");
  res.header("Access-Control-Allow-Headers", "Content-Type");
  next();
});

---

Java Spring (스프링 CORS 설정)

@CrossOrigin(origins = "https://yourfrontend.com")
@RestController
public class MyController {
  ...
}

---

✅ 8. 면접 질문 예시 + 해설

---

❓ Q. CORS는 무엇이고, 왜 필요합니까?

✅ A.

• CORS는 다른 출처에서 자원을 요청하는 Ajax 요청을 제한하거나 허용하는 보안 정책입니다.
• 출처가 다르면 브라우저는 요청을 차단하지만,
• 서버가 Access-Control-Allow-Origin 헤더로 특정 출처를 명시적으로 허용하면 브라우저가 요청을 허용합니다.
• POST, PUT 요청이나 커스텀 헤더 사용 시에는 Preflight(OPTIONS) 요청이 선행됩니다.

---

✅ 전체 요약 카드

항목	설명
CORS	다른 도메인에서 오는 Ajax 요청 허용 정책
Origin	프로토콜 + 도메인 + 포트
Access-Control-Allow-Origin	서버가 허용하는 출처 지정
Preflight	위험한 요청 전에 OPTIONS로 사전 허락 요청
안전한 요청	GET, POST + 기본 헤더만 쓰는 요청
허용 응답	CORS 헤더가 반드시 있어야 브라우저가 허용

✅ 5-2단계: CSRF(Cross-Site Request Forgery) 방지 전략 완전 정복

CSRF는 사용자의 의도와 무관하게 악의적인 요청이 자동으로 서버에 전송되는 공격입니다.

브라우저와 Ajax 기반 인증에서 반드시 방어해야 하는 보안 위협이에요.

---

✅ 1. CSRF 공격이란?

---

📦 정의

Cross-Site Request Forgery = 사이트 간 요청 위조

---

👦🏻 쉬운 설명

로그인된 사용자가 무심코 악성 사이트를 열었는데,

그 사이트가 몰래 내 쿠키를 사용해서 서버에 요청을 보내버리는 공격!

---

❗ 예시 시나리오

1. 사용자가 bank.com에 로그인 (쿠키로 인증됨)
2. 공격자가 evil.com에 가짜 요청을 숨겨둠
3. 사용자가 evil.com을 방문하자마자, 다음 요청이 자동으로 실행됨:

<img src="https://bank.com/transfer?to=hacker&amount=10000">

✅ 쿠키는 자동으로 함께 전송됨

✅ 사용자는 아무것도 안 했는데 돈이 빠져나감!

---

✅ 2. 왜 발생할까?

• 브라우저는 같은 사이트로 가는 요청이면 쿠키를 자동으로 넣어줌
• 악성 사이트도 동일한 주소로 요청하면 쿠키가 따라감
• 서버는 요청이 “진짜 사용자”라고 착각함

---

✅ 3. 방지 방법 ①: SameSite 쿠키 정책

---

📦 SameSite 속성이란?

브라우저가 이 쿠키는 다른 사이트에서 자동으로 보내지 말아라 라고 설정하는 방법

---

SameSite 옵션 3가지

설정	설명
Strict	다른 사이트에서 오는 요청에는 절대 쿠키 안 보냄 🔐
Lax	GET 요청만 쿠키 보냄 (폼, 링크 클릭 정도)
None	모든 요청에 쿠키 보냄 (단 Secure 필요) ⚠️

---

✅ 추천 설정 (보안 우선)

Set-Cookie: sessionId=abc123; SameSite=Strict; Secure

✅ 이렇게 하면 외부 사이트에서 Ajax 요청해도 쿠키가 따라가지 않음

→ CSRF 방지 완료! 🛡️

---

✅ 4. 방지 방법 ②: CSRF 토큰 사용

---

📦 개념

클라이언트(브라우저)에 서버가 발급한 CSRF 토큰을 숨겨서 저장하고,

Ajax 요청마다 함께 보내서 서버가 “정상적인 요청인지”를 확인하는 방식

---

👦🏻 쉬운 설명

일종의 “비밀 도장”을 주고, 요청할 때마다 도장을 찍어서 보낸다고 보면 됩니다.

---

🔧 흐름 순서

1. 사용자가 페이지에 접근하면 서버가 CSRF 토큰을 생성해서 <meta> 태그에 넣음

<meta name="csrf-token" content="abc123">

1. Ajax 요청 시 이 값을 헤더로 함께 보냄

const csrf = document.querySelector("meta[name='csrf-token']").content;

fetch("/transfer", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-CSRF-Token": csrf // 👉 토큰 전송
  },
  body: JSON.stringify({ to: "friend", amount: 100 })
});

1. 서버는 이 토큰이 유효한지 검사하고 요청을 허용

---

✅ 서버에서 하는 일

// 서버에서 세션에 저장된 토큰과 요청에서 받은 토큰을 비교
if (req.headers['x-csrf-token'] !== req.session.csrfToken) {
  return res.status(403).send("CSRF 공격 탐지됨!");
}

---

✅ 5. CSRF 토큰 + SameSite 조합 = 최강 보안

전략	설명
SameSite=Strict	외부 요청엔 쿠키 안 보냄
CSRF 토큰	내부 요청이라도 토큰 확인 안 되면 차단

→ 둘 다 쓰면 실수 없이 완벽 방어 가능!

---

✅ 6. 실무 팁: 프론트엔드에서 안전하게 토큰 보내는 법

• 서버가 <meta> 태그 또는 cookie에 토큰을 넣어둠
• JavaScript가 Ajax 요청에 X-CSRF-Token 헤더로 함께 전송
• 서버는 이 값을 세션 또는 DB에 저장된 값과 비교

✅ 이렇게 하면 폼 전송도, Ajax도 안전하게 동작

---

✅ 면접 질문 예시 + 해설

---

❓ Q. CSRF 공격이란 무엇이며, 이를 어떻게 방어하시겠습니까?

✅ A.

• 사용자가 로그인된 상태에서 외부 사이트가 쿠키를 자동으로 사용하는 요청을 보내 사용자 모르게 요청이 실행되는 공격입니다.
• 이를 방지하기 위해 브라우저가 쿠키를 자동으로 보내지 않도록 SameSite=Strict 속성을 설정하고,
• Ajax 요청 시 서버가 발급한 CSRF 토큰을 함께 전송하고 검증하는 방식을 사용합니다.

---

✅ 전체 요약 카드

개념	설명
CSRF	다른 사이트가 자동으로 인증된 요청을 보내는 공격
SameSite	쿠키 자동 전송 제한 (Strict가 가장 안전)
CSRF 토큰	서버가 발급한 도장처럼, 요청마다 함께 보내서 인증
방어 전략	SameSite + CSRF 토큰 조합
Ajax 적용	헤더에 X-CSRF-Token 포함해서 서버 검증 유도

---

---

✅ 5-3단계: XSS(Cross-Site Scripting) 방지와 안전한 JSON 응답 설계

🦠 XSS는 사용자가 입력한 값이 스크립트로 실행되어 해킹되는 대표적인 공격입니다.

서버가 JSON 응답을 줄 때도 XSS에 매우 주의해야 합니다.

---

✅ 1. XSS란?

---

📖 정의

XSS = Cross-Site Scripting

다른 사람의 브라우저에서 자바스크립트가 강제로 실행되게 만드는 공격

---

👦🏻 쉬운 예

<!-- 사용자가 입력 -->
<script>alert("해킹됨")</script>

→ 이게 그대로 화면에 출력되면?

→ 🔥 다른 사용자의 화면에서 경고창이 뜨거나,

→ 🕵️‍♂️ 쿠키가 훔쳐지고, 비밀번호가 탈취될 수 있어요.

---

❗ 특히 위험한 경우

• 사용자가 입력한 내용이 서버에 저장됨
• 다른 사용자가 그 내용을 HTML로 볼 때 <script>가 그대로 실행됨
• 또는 Ajax로 받아온 JSON 데이터에 스크립트가 포함돼 있으면?

→ 바로 JSON XSS가 터질 수 있어요!

---

✅ 2. JSON 응답은 왜 위험할까?

---

📦 예시 (위험한 응답)

{
  "username": "<script>alert('XSS')</script>"
}

👨🏻‍🏫 이걸 HTML에 이렇게 출력하면?

<p>${data.username}</p>

→ 결과:

<p><script>alert('XSS')</script></p>

→ 🔥 자바스크립트 실행됨 → 브라우저 해킹됨

---

✅ 3. 안전한 JSON 응답 설계 방법

---

✅ 1) Content-Type 명확히 설정

Content-Type: application/json

• 브라우저에게 “이건 스크립트가 아니라 JSON이야!” 라고 알려주는 것
• ❗ text/html 이면 브라우저가 HTML처럼 렌더링하려 함 → 위험

---

✅ 2) 문자열 이스케이프(escape) 처리

---

📦 이스케이프란?

”, <, > 등 HTML에서 위험한 문자를 다른 코드로 바꿔서 무해화하는 것

---

예시

원래 문자	이스케이프
<	\u003c
>	\u003e
&	\u0026
'	\u0027

---

📦 안전한 JSON 예시

{
  "username": "\u003cscript\u003ealert('XSS')\u003c/script\u003e"
}

→ 브라우저는 이걸 스크립트가 아닌 단순 문자열로 처리

→ ✅ 절대 실행되지 않음!

---

✅ 4. 서버에서 안전하게 JSON 응답하는 방법

---

Node.js (Express)

res.setHeader("Content-Type", "application/json");
res.send(JSON.stringify(data)
  .replace(/</g, "\\u003c")
  .replace(/>/g, "\\u003e")
  .replace(/&/g, "\\u0026")
  .replace(/'/g, "\\u0027"));

---

Java (Spring)

// Jackson JSON 설정
@Bean
public ObjectMapper objectMapper() {
    return new ObjectMapper()
        .configure(JsonGenerator.Feature.ESCAPE_NON_ASCII, true);
}

---

✅ 5. 추가 보안: Content Security Policy (CSP)

---

📦 CSP란?

브라우저에게 “이 사이트에선 외부 스크립트 실행 금지해줘!”라고 명령하는 보안 헤더

---

예시

Content-Security-Policy: default-src 'self';

• 'self' → 내 도메인 외에는 스크립트 실행 금지
• <script src="http://hacker.com/xss.js"> → 차단됨 ✅

---

✅ 6. 면접 질문 예시 + 해설

---

❓ Q. JSON 응답에서도 XSS가 발생할 수 있나요? 그렇다면 어떻게 방지하나요?

✅ A.

• JSON 응답 내용에 <script> 같은 태그가 포함되면, 이를 화면에 출력하는 순간 XSS가 실행될 수 있습니다.
• 이를 방지하기 위해 서버는 Content-Type: application/json을 명시하고,
• JSON 문자열 내 <, >, &, ' 등의 특수문자를 유니코드로 이스케이프 처리해야 합니다.
• 또한, 브라우저에는 Content-Security-Policy를 적용해 외부 스크립트 실행을 차단하는 것도 효과적입니다.

---

✅ 전체 요약 카드

항목	설명
XSS	악성 스크립트가 사용자 브라우저에서 실행되는 공격
JSON XSS	JSON 안에 <script>가 포함되어 있으면 위험
Content-Type	application/json으로 명확히 설정
이스케이프	<, >, & 등을 안전한 코드로 변환
CSP	외부 스크립트 실행 차단 보안 정책