| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
- Java
- 자바
- 프로세스
- Do it! 자료구조와 함께 배우는 알고리즘 입문
- 시간 복잡도
- 브루트포스
- LG유플러스 유레카 부트캠프
- 백준
- 프론트엔드 비대면반
- 재귀
- 유레카 부트캠프
- 멀티캠퍼스IT부트캠프
- tanstack query
- 웹시큐리티
- LG유플러스 유레카 프론트엔드
- zod
- 애자일
- 부트캠프후기
- 코딩
- 소수
- 별찍기10
- git branch 협업
- LG유플러스 유레카 프론트엔드 개발자
- 멀티캠퍼스IT부트캠프티
- LG유플러스 유레카 3기 프론트엔드
- 정렬
- 알고리즘
- 스레드
- 프론트엔드
- 2775번 문제
- Today
- Total
개발 일기
20251202 웹시큐리티 본문
들어가며
유레카에서 웹시큐리티 과목수업을 들었다. 보안사고가 잦은 요즘이라 수업에 더 몰입해서 들을 수 있었다.
보안은 전문가가 따로 있을 만큼 중요하고 어려운 것 같다. 그래서 수업 때 들은 내용과 추가적으로 공부한 내용을 정리해보려고 한다.

웹 시큐리티
1. HTTP Request/Response 이해

HTTP란?
HTTP(HyperText Transfer Protocol)는 하이퍼텍스트(HTML) 문서를 교환하기 위해 만들어진 protocol(통신 규약)이다.
웹에서 이루어지는 모든 데이터 교환의 기초이고 클라이언트-서버 프로토콜이다.
- 클라이언트 요청을 생성하기 위해 연결을 연 다음 응답을 받을 때까지
기다리는 모델, 각각의 요청은 클라이언트에 의해 초기화된다.
- 이 둘은 데이터 스트림이 아닌 개별적인 메시지 교환을 통해 통신한다.
- 클라이언트에 의해 전송되는 메시지를 요청(requests)이라 하고, 요청에 대해
서버에서 응답으로 전송하는 메시지를 응답(responses)이라고 한다.
Request

Accept
클라이언트가 서버로부터 받을 수 있는 미디어 타입을 지정하는 데 사용한다.
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8:
클라이언트는 HTML과 XHTML을 가장 선호하며, XML은 조금 덜 선호하고, 그 외의 모든 타입(*/*)은 더 낮은 선호도로 받을 수 있다.
Upgrade-Insecure-Requests: 1
클라이언트가 서버에게 HTTP로 요청한 리소스가 있는 경우 가능하면 HTTPS로 해당 리소스를 제공해 달하는 요청이다.
Response

Vary
클라이언트에게 서버가 결정을 내릴 때 어떤 헤더를 기반으로 콘텐츠를 선택했는지 알려준다.
X-Content-Type-Options
주로 웹 브라우저가 MIME 타입을 추측(sniff) 하지 않도록 하고, 서버가 명시한 Content-Type 헤더의 값을 그대로 따르도록 강제하는 데 사용한다. 이 헤더는 보안을 강화하기 위한 목적으로 사용되며, 특히 MIME 타입 추측을 통한 공격을 방지하는 데 도움이 된다. nosniff 설정은 웹 브라우저 응답에 포함된 리소스의 Content-Type을 변경하거나 추측하지 않고, 서버에서 지정한 대로 처리한다.
X-XSS-Protection
브라우저의 XSS 필터 설정, 0은 브라우저 XSS 필터 비활성화 상태이다.
1; mode=block은 브라우저 XSS 필터를 활성화하고 XSS 공격이 감지되면 해당 페이지의 로딩을 차단한다.
Pragma
HTTP/1.0에서 Cache 제어를 위해 사용된다. HTTP/1.1에서는 Cache-Control 헤더로 대체되지만 하위 호환성을 위해 둘 다 사용한다.
2. CORS(Cross-Origin Resource Sharing)

CORS란 웹 브라우저에서 실행 중인 JavaScript가 다른 출처(도메인, 프로토콜, 포트)의 리소스에 접근할 때 적용되는 보안 메커니즘이다. 이는 악의적인 웹사이트가 사용자의 데이터에 무단으로 접근하는 것을 방지하기 위한 중요한 보안 기능이다.
CORS 문제를 왜 해결해야 하는가?
1. 사용자 경험 : CORS 오류가 발생하면 API 요청이 실패하고 사용자는 애플리케이션의 기능을 사용할 수 없게 된다.
2. 보안과 기능성의 균형 : CORS는 보안을 위해 존재하지만, 정당한 교차 출처 요청도 차단할 수 있어 적절한 구성이 필요하다.
3. 현대적 웹 아키텍처 : 프론트엔드와 백엔드가 분리된 현대적 웹 개발에서는 서로 다른 출처에서 통신하는 경우가 일반적이므로 CORS 설정이 필수적이다.
4. 법적 규정 준수 : 일부 데이터 보호 규정은 적절한 보안 조치를 요구하며, CORS는 이러한 요구 사항의 일부이다.
CORS 오류 해결 방법
1. 서버 측 설정
가장 일반적이고 권장되는 방법이라고 한다.
// 기본 설정
app.use(cors());
// 세부 설정을 통한 보완
const corsOptions = {
origin: ['https://yourfrontend.com', 'http://localhost:3000'],
methods: ['GET', 'POST', 'PUT', 'DELETE'],
allowedHeaders: ['Content-Type', 'Authorization'],
credentials: true,
maxAge: 86400
};
app.use(cors(corsOptions));
2. 프록시 사용
개발 환경에서는 프론트엔드 개발 서버의 프록시 기능을 사용할 수 있다.
// React 프로젝트의 package.json에 추가
"proxy": "http://localhost:3000"
3. 적절한 응답 헤더 설정
Express 없이 Node.js만 사용하는 경우
response.setHeader('Access-Control-Allow-Origin', 'https://yourfrontend.com');
response.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
response.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
response.setHeader('Access-Control-Allow-Credentials', 'true');
4. 보안 모범 사례
- 와일드카드() 대신 명시적인 origin 목록 사용
- 필요한 HTTP 메서드만 허용
- 쿠키/인증 정보가 필요한 경우에만 credentials: true 설정
- 프리플라이트 요청 캐싱으로 성능 최적화
3. Ajax, XMLHttpRequest, Fetch API

Ajax란?
Asynchronous JavaScript and XML의 약자로, 자바스크립트와 XML을 이용한 비동기적 정보 교환 기법이다.
요즘은 XML보다는 JSON을 주로 사용한다. 브라우저의 XMLHttpRequest를 이용해 전체 페이지를 새로 가져오지 않고도 페이지 일부만을 변경할 수 있도록 javascript를 실행해 서버에 데이터만을 별도로 요청하는 기법이다.
XMLHttpRequest(XHR)
서버와 통신을 하도록 하는 객체이다.
- 객체는 서버와 상호작용하기 위해 사용된다.
- 전체 페이지를 새로고침하지 않아도 URL을 통해 데이터를 전송하거나 받아올 수 있다.
- XML 데이터 통신 X, 모든 종류의 데이터를 받아올 수 있다.
- 객체는 브라우저에서 제공하는 API이다.
Fetch API
Fetch API는 네트워크 통신을 포함한 리소스 취득을 위한 인터페이스를 제공하며, XMLHttpRequest보다 강력하고 유연한 대체제라고 한다. (mozilla.org 피셜)
Fetch API는 Request와 Response 객체 그리고 기타 네트워크 요청에 관련된 것들을 사용하고, CORS와 HTTP Origin 헤더 행동 등 관련한 개념도 포함하고 있다.
수업시간 실습
웹 시큐리티 과목을 배우며 프론트반인만큼 웹브라우저에 설명을 띄우기 위한 코드들을 작성했다.
CSS 코드도 작성했기에 조금 더 공부할 맛 나는? 웹페이지가 되었다.

느낀 점
일단 웹 보안에 대한 지식이 늘어난 것 같아서 기분이 좋았다. 그리고 프론트엔드 개발자의 특성을 살려 웹 페이지에 예쁜 글을 올려두고 기능동작으로 테스트 해볼 수 있게 진행해본 경험도 도움이 많이 되었다.
그리고 강사님이 노션에 준비해두신 자료를 더 읽어보면서 더 깊이 있게 알 수 있었고 추가적으로 구글링과 문서들을 읽어보며 HTTP, CORS, 비동기 통신 등에 대한 이해를 넓힐 수 있었다.
'TIL' 카테고리의 다른 글
| 251223 소프트웨어와 개발 프로세스 (0) | 2025.12.23 |
|---|---|
| 20251215 깃브랜치협업 (0) | 2025.12.15 |
| 20251120 리액트 복습하고 정리(1) (0) | 2025.11.20 |
| 20251118 Axios는 뭘까? (0) | 2025.11.18 |
| 20251110 SPA, MPA, CSR, SSR의 차이 (1) | 2025.11.11 |