🔒 초보자도 10분 만에 이해하는 웹 보안의 핵심 구조

🔒✨ 웹 보안 핵심 개념 총정리

(진짜 개발자 아니어도 이해되게 설명 버전)

 

보안 = 해커랑 싸우는 기술이 아니라
“정상 유저만 편하게 들어오게 문을 설계하는 기술” 이다.

 

아래 내용은 어느 웹사이트든 공통으로 쓰이는 개념들이라,
그냥 “아~ 이런 원리구나” 감 잡는 용도라고 보면 돼 😊

 

---

1️⃣ XSS (Cross-Site Scripting)

🧨 한 줄 정의

“내 페이지에 상대방 스크립트를 넣는 공격”

 

• 한 단어로: 삽입(injection) 공격
• 공격자가 글쓰기, 댓글, 검색창 같은 곳에
  자바스크립트 코드를 몰래 끼워 넣는 거야.
  → 즉 “텍스트인 척하는 악성 코드”를 심어두는 방식.

 

예를 들어, 이런 게 그대로 저장되고 실행되면:

<script>alert("Hacked")</script>

 

브라우저는 이걸 “그냥 텍스트”가 아니라
진짜 자바스크립트 코드로 실행해버려.
→ 사용자는 아무 행동을 안 했는데도 코드가 실행됨.

 

😱 XSS를 통한 공격들

• 로그인 쿠키 훔치기
  → document.cookie를 빼내 공격자 서버로 전송 가능
• 화면에 가짜 버튼/가짜 폼 띄우기
  → 유저가 속아서 정보 입력할 수 있음
• 자동으로 악성 사이트로 이동시키기
• 브라우저 안에서 사용자의 행동을 몰래 감시

 

🛡 XSS 방어 개념 (원리만)

• 입력 값 정리하기 (sanitize)
  <script>, <iframe>, onerror=... 같은 거 다 잘라내기
  → 즉, 위험한 태그를 입구에서 거르고 들어오지 못하게 함.
  
  
• 출력할 때 이스케이프(escape)
  HTML 태그(<script>, <img> 등)를 실제 코드로 실행하지 않도록
  브라우저가 “그냥 글자”로 보게 < → <, > → > 로 변환해서 출력하는 방식.
  → 태그는 화면에 보이되, 절대 실행되지 않는 “글자”로 변환됨.
  
  
• 에디터에서는 화이트리스트
  에디터·댓글처럼 사용자가 HTML을 입력하는 환경에서는
  필요한 태그만 허용하고 (<b>, <i>, <p>, <img> 등)
  <script>, <iframe>, onerror= 같은 위험 태그/속성은 아예 제거해서
  악성 스크립트가 들어오지 못하게 차단하는 방식.
  → 즉 “필요한 애들만 들여보내고 나머지는 문 앞에서 컷.”
  
  
• CSP(Content-Security-Policy)
  “이 사이트는 여기서 온 스크립트만 실행할게요” 라고 브라우저에게 말해주는 보안 규칙
  → 브라우저에게 “이 리소스를 어디서 받아올지” 지정하는 정책
  → 외부에서 삽입된 악성 스크립트 실행을 원천적으로 차단할 수 있음.

 

---

2️⃣ CSRF (Cross-Site Request Forgery)

🛡 한 줄 정의

“남이 나 대신 요청을 보내버리는 공격”

 

한 단어로: 위조(forgery)

사용자의 로그인 상태를 이용해서,
쿠키 자동 전송 기능을 이용해,
본인이 의도하지 않은 요청을 자동으로 보내게 만듦.
→ 공격자가 “유저의 브라우저”를 조종하는 느낌.

 

큰 틀에서 보면 브라우저 보안 흐름은 이렇게 흘러간다.

처음부터 있던 룰: SOP (Same-Origin Policy)
브라우저는 초창기부터:

 

“다른 사이트에서 온 JS가
내 민감한 데이터를 막 건드리면 안 된다”

 

라는 기본 보안 모델(SOP)을 가지고 있었다.
즉, 다른 Origin에서 온 JS가 내 쿠키·응답·DOM 같은 데이터를 “읽는 것”을 막는 규칙이다.

 

하지만 브라우저는 점점 더 ‘친절해졌다’

• 쿠키 자동 전송
• 로그인 세션 자동 유지
• 토큰 자동 포함

이런 기능들 덕분에 사용자는 편해졌지만,
이 자동화를 악용하는 공격(대표적으로 CSRF)이 등장했다.

왜냐면 SOP는 “JS가 다른 Origin의 데이터를 읽는 것” 은 막아주지만,
“HTML 태그가 만드는 단순 HTTP 요청” 까지는 막지 못했기 때문이다.

 

예:

너는 은행 사이트 로그인 상태고,
누가 만든 사이트에 접속했더니 그 안에 이런 이미지가 숨어 있음:

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

 

→ 이미지는 자동 로드됨
→ 브라우저는 로그인 쿠키를 붙여 요청함
→ 서버는 “유저가 직접 보낸 정상 요청”으로 착각
→ 클릭 한 번 안 했는데 송금됨

 

즉, 악성 사이트는 은행 쿠키를 '읽을 수 없다'.
하지만 브라우저는 은행으로 가는 요청에 '자동으로 그 쿠키를 붙인다'.
그래서 악성 사이트가 유저인 척 요청을 보내버릴 수 있다.
→ 이게 CSRF.

 

XSS vs CSRF 감각 비교

• XSS: “스크립트 삽입 공격”
  → 공격 코드를 내 페이지 안에 심어버리는 방식
• CSRF: “요청 위조 공격”
  → 악성 사이트가 내 브라우저를 조종해서 요청 보내기

🛡 CSRF 방어 개념

• CSRF 토큰
  → 서버가 매 요청마다 검증하는 랜덤 키
  
  
• SameSite 쿠키
  → 다른 사이트에서 자동으로 발생한 요청엔 쿠키가 안 붙도록 제한하는 옵션
  (특히 Lax/Strict 설정일 때 CSRF를 크게 줄여준다)
  → 현대 브라우저 기본값
  2020년 이후 주요 브라우저(Chrome, Edge, Firefox, Safari 등)는 `SameSite`를 따로 지정하지 않으면 기본적으로 `SameSite=Lax`로 취급한다. 실무에서는 “요즘 브라우저 = SameSite=Lax 기본 내장”이라고 봐도 거의 무방하다.
  
  
• Origin / Referer 검사
  → “이 요청이 진짜 우리 사이트에서 왔나?” 체크
  
  

---

3️⃣ CORS (Cross-Origin Resource Sharing)

🌐 CORS가 정확히 뭐냐?

브라우저가 “이 웹사이트(origin)에서 실행된 JS가
저 서버(API)를 불러도 되는지?” 확인하기 위해,
해당 웹사이트를 관리하는 서버가 제공한 ‘허용 리스트(Origin 목록)’을 보고 판단하는 규칙

 

쉽게 말하면:

“이 웹 페이지에서 실행 중인 스크립트가
외부 서버에 API 요청 보내도 되나?”

브라우저가 (해당 웹페이지를 관리하는 서버에게 물어서) 대신 확인해주는 시스템.
쉽게 말하면 브라우저는 문지기, 해당 웹페이지를 관리하는 서버는 내부 허용목록 작성자

🌋 왜 이런 규칙이 생긴 걸까?

그리고 현대 웹 구조는 분리되었다
요즘 서비스는:

• 프런트: https://www.magix-tarot.com
• API: https://api.magix-tarot.com

이렇게 서로 다른 Origin에 프런트/백엔드를 나누는 구조가 기본값이 됐다.
그런데 SOP를 그대로 적용하면:

“Origin이 다르니까 JS로 응답 읽으면 안 돼!”

 

가 되어, 정상적인 cross-origin API 호출까지 막히는 문제가 생긴다.

 

정상적인 교차 호출도 필요해졌다

SOP 입장에서 보면:

“Origin이 다르네? 그럼 JS가 응답을 읽으면 안 되지!”
→ 기본적으로 차단 ❌

 

하지만 서비스 입장에서는:

“둘 다 우리 서비스인데…
프런트에서 API 응답을 못 읽으면
SPA / 프론트엔드 앱 자체가 동작을 못 하는데?”

 

이 딜레마를 해결하기 위해 나온 게 CORS다.

CORS의 핵심 아이디어는 이거다:

“원래 SOP 때문에 막히는 cross-origin 응답이지만,
서버가 명시적으로 ‘이 Origin은 허용’이라고 말해주면
브라우저가 예외적으로 읽을 수 있게 해 주자.”

 

그래서 API 서버가 이런 헤더를 추가해서 응답하면:

Access-Control-Allow-Origin: https://www.magix-tarot.com

 

브라우저는 이렇게 판단한다:

“요청 보낸 쪽 Origin이 https://www.magix-tarot.com 이고,
서버도 그 Origin을 허용한다고 했네?

→ 그러면 이 응답은 JS에서 읽을 수 있게 허용해도 되겠다.”

 

즉,

• 막는 기본 룰: SOP (브라우저)
• 예외를 열어주는 것: CORS 헤더를 보내는 서버

이 조합으로:

• 공격자가 엉뚱한 Origin에서 API 응답을 읽는 건 계속 막으면서
• 우리 서비스 프런트 (www.magix-tarot.com) ↔ 우리 API (api.magix-tarot.com) 처럼
  정상적인 cross-origin 통신만 예외적으로 허용할 수 있게 된다.

 

⭐ 끝까지 한 번에 요약

• SOP
  • 브라우저가 처음부터 가지고 있던
    “다른 Origin에서 온 JS는 내 민감한 데이터를 읽지 마라” 룰
• CSRF
  • SOP는 “데이터 읽기(read)”만 막고,
    HTML 태그가 만드는 “요청(send)”은 막지 못한다는 틈을 파고든 공격
  • 브라우저의 쿠키 자동 전송 기능을 악용
• CORS
  • SOP 때문에 기본적으로 막히는 cross-origin 응답들 중에서
    “이 Origin은 괜찮다”라고 서버가 화이트리스트 형태로 허용하는 예외 시스템
  • 공격자는 여전히 막고,
    정상적인 프론트 ↔ API 통신만 열어주기 위한 장치

---

4️⃣ Origin / Host / Referer 차이

https://magix-tarot.com 예시로 직관적으로!

🏷 Origin (출발지)

JS가 실행된 “웹페이지”의 출처

 

유저가 방문한 페이지:

https://www.magix-tarot.com/ko/blogs

 

 

→ 요청 헤더 Origin:

Origin: https://www.magix-tarot.com

 

(즉, “이 JS는 magix-tarot.com에서 실행되었습니다”라고 브라우저가 말하는 것.)

 

🏷 Host (도착지 서버)

요청이 최종 도달하는 서버(목적지)

 

예:

fetch("https://api.magix-tarot.com/posts")

 

→ 요청 헤더 Host:

Host: api.magix-tarot.com

 

(즉, “요청이 도착하는 진짜 서버 주소는 여기입니다.”)

 

🏷 Referer (정확한 출발 URL)

이 요청을 발생시킨 ‘정확한 페이지 전체 주소’

 

예:

Referer: https://www.magix-tarot.com/ko/blogs/123

 

→ 로그·보안용으로 많이 쓰임
→ Origin보다 더 구체적인 정보가 담김

 

⭐ 추가 설명 — 왜 보통 Origin과 Host가 같은가? (SOP 때문에!)

브라우저에는 기본적으로 SOP(Same-Origin Policy) 라는 강력한 보안 규칙이 있음.

SOP = “같은 Origin(출발지)끼리만 통신해라!”

 

그래서 전통적인 웹사이트 구조는 이렇게 설계됐음:

웹페이지 Origin: https://site.com
API Host: https://site.com/api

 

둘 다 같은 도메인이라:

• Origin = site.com
• Host = site.com
• Referer = site.com/경로
  → CORS 필요 없음 (브라우저가 기본적으로 허용)

즉, “옛날 웹사이트 대부분은 Origin=Host가 같았다.”

 

✨ modern 웹에서는 Origin ≠ Host가 흔함

요즘은 서비스가 분리되어 있음:

• 프런트: www.magix-tarot.com
• API: api.magix-tarot.com
• CDN: cdn.magix-tarot.com
• Auth: auth.magix-tarot.com

즉:

Origin: https://www.magix-tarot.com
Host: api.magix-tarot.com

 

이 구조는 SOP 기준 “서로 다른 origin”이라
브라우저가 기본적으로 막아버림.

 

그래서 등장한 게 바로 CORS:

“브라우저야, 얘는 다른 Origin이긴 하지만
허용해도 돼~” 라고 알려주는 승인 시스템.

 

⭐ 한눈에 정리

항목	값	의미
Origin	https://www.magix-tarot.com	JS가 실행된 출발지 (도메인 단위)
Host	api.magix-tarot.com	요청이 도착한 서버 주소
Referer	https://www.magix-tarot.com/ko/blogs/123	정확한 상세 출발 주소
SOP	같은 Origin끼리만 허용	Origin=Host가 보통 같은 이유
CORS	SOP 예외 승인 시스템	Origin≠Host일 때 필요

 

---

5️⃣ User-Agent 스푸핑

User-Agent는 UA(User-Agent) = ‘브라우저가 서버에 보내는 자기소개 문자열’
즉, 단순 문자열이기 때문에 아무나 바꿀 수 있음:

curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://example.com

 

→ UA 속에 “Mozilla” 있다고 진짜 브라우저는 아님
→ UA만으로 판단 못하고
IP + Origin + 요청 패턴 같이 봐야 정확함.

 

---

6️⃣ IP Spoofing이 웹에서 거의 안 통하는 이유

(Cloudflare 기준 실제 시나리오 + 정확한 기술 맥락 버전)

IP 스푸핑 = 출발지 IP를 속여서 요청을 보낸 척하는 공격

 

하지만 “웹(HTTP) 공격”에서는 성공 자체가 사실상 불가능
→ 이유: TCP의 3-Way Handshake 때문
→ (단, 아래에서 설명하듯 “L3/L4 DDoS” 같은 저층 공격에서는 여전히 쓰임)

 

🧩 TCP 3-Way Handshake = 접속을 여는 악수 절차

1) SYN — “나 연결하고 싶어!”
2) SYN/ACK — “좋아, 나 준비됐어. 너도 받았다는 신호 보내!”
3) ACK — “응, 받았어! 이제 연결 시작하자!”

 

이 3단계 중 하나라도 실패하면
TCP 연결은 시작되지 않음 → HTTP 요청 자체를 보낼 수 없음.

 

⚡ Cloudflare 기준 실제 동작 예시

공격자가 “마기 IP로 위장한 SYN”을 Cloudflare에 보냄.

 

✔ 1) Cloudflare는 SYN을 받음

(출발지가 마기 IP로 되어 있음)

 

✔ 2) Cloudflare는 SYN/ACK를 “마기의 실제 집 IP”로 보냄

→ 왜냐면 공격자가 적어둔 ‘가짜 출발지 IP’가 바로 그곳이니까.

 

✔ 3) 공격자는 Cloudflare가 보낸 SYN/ACK를 절대 받을 수 없음

→ SYN/ACK는 마기 집으로 가버림.

 

✔ 4) 공격자는 마지막 ACK를 보낼 수 없음

→ handshake 실패
→ TCP 연결 생성 불가
→ HTTP 요청 불가능

 

즉,
웹 공격으로는 아예 성립조차 안 됨.

 

 

🔍 하지만 기술적으로 정확히 말하면?

❌ "IP 스푸핑 = 완전히 의미 없음" → 이건 틀림

✔ "웹 계층(HTTP·쿠키·세션) 공격에서는 의미 없음" → 이게 정확함

 

왜냐면:

🟡 L4 이하(L3/L4)에서는 의미가 있음

예)

• SYN flood
• UDP reflection/amplification
• 랜덤 IP 분산 공격
  → 이런 건 TCP 세션을 끝까지 만들 필요 없음
  → handshake가 필요 없거나, 첫 SYN만 보내도 되기 때문.

즉,
네트워크 계층(DDoS)에서는 아직도 쓰이고, 지금도 위험함.

 

🔵 하지만 L7(웹) 공격에서는 의미 없음

HTTP 요청은 반드시 TCP handshake를 통과해야 함.

IP 스푸핑으로는:

• 쿠키 접근 불가능
• 세션 사용 불가능
• 로그인 토큰 전송 불가능
• CSRF/XSS 악용 불가능
• 인증이 필요한 API 호출 불가능

→ 웹 서비스 공격에는 사실상 무력.

 

 

🎯 최종 한 줄 정리 (정확 버전)

IP 스푸핑은 L3/L4 DDoS에서는 여전히 의미 있지만,
TCP 3-Way Handshake 때문에
HTTP·세션·쿠키를 다루는 “웹 공격(L7)”에서는
사실상 불가능하다.

 

공격자들은 그래서 결국:

• VPN
• Proxy
• 클라우드 서버
  같이 “실제로 응답을 받을 수 있는 진짜 IP”만 사용한다.

 

---

7️⃣ JWT & Short-Lived 토큰 철학

JWT = 서버가 서명해주는 디지털 신분증

들어가는 내용:

• user id
• 권한
• 만료(exp)
• claims들

왜 짧게 살아야 하나?

→ 탈취되었을 때 피해 기간 최소화
→ “털렸네? 하지만 5분 뒤면 못 써요~” 이런 구조

 

---

8️⃣ 서버 요청 vs 브라우저 요청 구분

브라우저 요청:

• Origin 있음
• Referer 있음
• CORS 적용
• CSRF 위험 존재
• 쿠키 자동 전송됨 (브라우저의 친절함 때문에 공격 표면이 넓음)
  → 브라우저는 쿠키·세션·DOM·JS 실행까지 포함된 “복합 환경”이라
  XSS, CSRF, CORS 같은 브라우저 전용 보안 위협이 생김.

 

서버 요청:

• Origin 없음
• Referer 없음
• CORS 없음
• 인증키(API 키/서비스 토큰)로 검증
• 쿠키 자동 전송 없음 (브라우저와 다르게 자동 기능이 없음)
  → 서버는 DOM·쿠키 자동 전송·JS 실행 같은 요소가 없어서
  브라우저 전용 공격(XSS·CSRF)이 성립하지 않음.
  대신 SQL Injection, 권한 오류, Rate Limit, SSRF, API 키 탈취 등
  서버 전용 보안 위협이 존재함.

 

⭐ 결론

브라우저는 쿠키 자동 전송·세션 유지·JS 실행 등
“인간을 편하게 해주는 기능”이 많아서 오히려 공격 표면이 넓어짐.
그래서 CORS, CSRF 토큰, SameSite 쿠키, CSP 같은
브라우저 전용 보안 장치가 필요함.

 

반대로 서버 요청은
쿠키 자동전송도 없고, JS 실행도 없고, DOM도 없기 때문에
브라우저 기반 공격(XSS/CSRF)은 통하지 않음.

 

→ 서버는 API 키·JWT 검증·RateLimit·Input Validation 등
서버 전용 보안에 집중하면 된다.

 

→ 즉, 둘 다 보안이 필요하지만
원리가 달라서 적용하는 기술이 다른 것.

 

---

9️⃣ 봇 차단 (Bot Filtering)

• User-Agent 패턴 분석
• isbot 라이브러리로 알려진 봇 감지
• sqlmap, dirbuster 같은 스캐너 차단
• 구글·네이버 봇은 allowlist로 허용

 

---

🔟 Rate Limit

• IP당 1분 40개 요청 → 차단
• 로그인 30초 10번 → 차단

목적:

• 스크래핑 방지
• 무차별 대입 공격 완화
• 서버 자원 보호

 

---

1️⃣1️⃣ CSP (Content-Security-Policy)

한 줄 정의

“이 사이트는 이곳에서 온 스크립트만 실행할게요”라고
브라우저에게 직접 선언하는 보안벽

 

예:

default-src 'self';
script-src 'self' https://trusted.scripts.example;
img-src 'self' https://images.example data:;
object-src 'none';

 

막아주는 것들:

• 외부 삽입 스크립트
• 악성 iframe
• object/embed
• inline script

→ 즉, “이 사이트에서 실행할 스크립트의 출처를 화이트리스트로 지정하는 정책”

 

---

1️⃣2️⃣ Cloudflare 같은 엣지 보안 레이어

엣지(전 세계 앞단)에서 공격을 먼저 걸러주는 1차 방패.

주요 기능:

• WAF
• Bot 관리
• 국가/ASN 차단
• Edge-Level Rate Limit
• DDoS 방어

→ “Cloudflare = 성문 앞 경비병”
→ “애플리케이션 보안 = 성 안쪽 경비병”

둘이 함께 있으면 이중 방어가 됨.

 

---

🎯 최종 요약 (초보자도 감 오는 핵심 정리)

• XSS: “내 웹페이지 안에 남의 스크립트가 몰래 심기는 공격”
  → 입력/출력 단계에서 필터링 + CSP로 실행 자체를 차단.
  
  
• CSRF: “내 브라우저를 악성 사이트가 조종해서 요청을 보내는 공격”
  → 쿠키 자동 전송이 원인.
  → CSRF 토큰 · SameSite · Origin 검증으로 방어.
  
  
• CORS: “브라우저가 출발지(origin)를 보고
  응답을 JS에서 읽을 수 있는지(읽기 권한)를 허용/차단하는 시스템”
  → Origin이 다르면 기본적으로 응답 읽기를 막고,
  서버가 CORS 헤더로 허용 리스트를 제공하면
  그 Origin에 한해서만 JS가 응답을 읽을 수 있게 해준다.
  
  
• Origin: “요청을 만든 웹페이지의 출발지(도메인 단위)”
• Host: “요청이 최종 도착하는 서버(목적지)”
• Referer: “요청을 발생시킨 ‘정확한 페이지 전체 URL’”
• UA(User-Agent) 스푸핑: “브라우저인 척 속일 수 있음”
  → UA만으로 판단 ❌ → IP·요청패턴·속도와 함께 분석해야 정확.
  
  
• IP 스푸핑: “출발지 IP를 속이는 공격”
  → TCP 3-way handshake에서 응답을 못 받아 실전 웹에서는 거의 불가능.
  → 그래서 공격자도 결국 VPN / Proxy/ Cloud servers 같은 ‘진짜 응답 가능한 IP’ 사용.
  
  
• JWT: “서버가 서명한 디지털 신분증 같은 토큰”
  → 유효시간을 짧게 해야 탈취 피해 최소화.
  
  
• 서버 vs 브라우저:
  → 브라우저는 쿠키 자동전송·세션 유지·JS 실행 때문에 공격 표면이 넓음 → CORS, CSP, 그리고 CSRF 방어장치(SameSite/토큰/Origin 검증)가 필요.
  → 서버는 XSS/CSRF는 없지만 Injection·SSRF·API키·RateLimit 같은 서버 전용 보안이 필요.
  
  
• 봇 필터 + Rate Limit:
  → 스캐너, 스크래퍼, 무차별 로그인·API 남용을 막는 1차 방어선.
  
  
• CSP: “이 사이트는 이 출처(script-src)의 스크립트만 실행할게요”
  → 외부 악성 스크립트, 인라인 스크립트 실행을 근본적으로 차단.
  
  
• Cloudflare: “우리 서버 앞에서 한 번 더 막아주는 엣지(Edge) 방패”
  → WAF, 봇 차단, 국가/ASN 차단, DDoS 방어 등 전 세계 네트워크 레벨에서 필터링.

 

---

🏰✨ 마기 사이트 보안 구조 — “4중 성벽 시스템”

 

“마기 사이트는 하나의 성이 아니라,
바깥에서 안쪽으로 여러 겹의 성벽을 통과해야만 접근할 수 있는 구조”

🧱 외성(Outer Wall): Cloudflare 보안 레이어

가장 바깥에서

• 악성 트래픽
• 자동화된 공격
• 의심스러운 IP/네트워크
• 대규모 요청

등을 1차로 걸러내는 외곽 방어선.
여기 통과하는 것부터가 이미 난이도 높은 첫 관문.

 

🧱 1차 내성(Inner Wall #1): Vercel Edge Layer

배포 플랫폼 차원의

• 프로토콜 검증
• 기본적인 접근 통제
• 정적 리소스 보호

등을 처리하는 두 번째 성벽.
외성 넘어온 요청도 여기서 다시 필터링됨.

 

🧱 2차 내성(Inner Wall #2): Application Firewall — middleware

여기서 애플리케이션 관점의 보안이 들어감:

• 비정상 경로 차단
• Bot 필터링
• Origin / Host 규칙 점검
• 속도 제한(Rate limit)
• 기본적인 요청 무결성 검증

등을 수행하는 세 번째 성벽.
사이트 구조를 가장 잘 아는 “내부 경비병” 역할.

 

🧱 3차 내성(Inner Wall #3): Token & Identity Security Layer

요청이 실제 사용자 환경에서 온 건지,
브라우저인지,
무결성이 유지되는지 등을 판단하는 토큰 기반 보안 성벽.

정상 요청만 내부 API 접근 가능.

 

🧱 4차 내성(Inner Wall #4): Copyright · 법률 · 지적재산 보호 레이어

프로젝트 자체의

• 콘텐츠 저작권
• 법률 규정 준수

같은 법적·제도적 보호막.
기술 보안을 넘어 “제도적 성벽”이 마지막 방어선 역할.

 

---

✨ 최종 요약

“Cloudflare 외성 → Vercel 성벽 → middleware 성벽 → Token 성벽 → 법률/저작권 성벽”
→ 이렇게 4중 이상의 방어선을 통과해야 실제 내부 로직에 닿을 수 있는 구조.

 

하나만 뚫어도 안 되고,
모두를 동시에 우회하는 건 사실상 불가능한 형태.

 

---

🔗 관련 링크

• 🔮 타로카드 해설 보러가기
• ✨ AI 타로 리딩 체험하기
• 📚 감정 카드 블로그 아카이브
• 📺 Magix Tarot 유튜브 채널
• 💬 카카오톡 1:1 오픈채팅 상담

 

© 2025 Magix Tarot | ⚠️ 저작권 안내
본 콘텐츠(텍스트, 이미지, 해설)는 「저작권법」에 따라 보호받습니다.
무단 복제, 편집, 2차 가공, 상업적 이용을 금하며, 위반 시 법적 책임을 물을 수 있습니다.