웹 보안 기초 및 CORS 해결 방안

웹 보안은 인터넷을 통해 제공되는 서비스와 사용자 데이터를 보호하는 일련의 과정과 기술을 의미한다. 현대 사회에서 웹은 금융 거래, 의료 정보, 개인적 소통, 정부 서비스에 이르기까지 거의 모든 생활 영역을 포괄한다. 따라서 웹 애플리케이션의 취약점은 개인의 개인정보 유출, 금전적 손실, 기업의 평판 훼손, 심지어 국가적 차원의 보안 위협으로까지 이어질 수 있다. 보안이 제대로 갖춰지지 않은 웹사이트는 해커에게 쉬운 표적이 되어 서비스 거부 공격(DDoS), 사이트 간 스크립팅(XSS), SQL 삽입(SQL Injection)과 같은 공격에 노출된다.

웹 보안의 중요성은 기술적 차원을 넘어 법적, 경제적 책임과 직결된다. 많은 국가에서는 개인정보보호법과 같은 법률을 통해 데이터 처리에 대한 엄격한 기준을 제시하고 있으며, 이를 위반할 경우 막대한 과징금이 부과된다. 또한, 한 번 손상된 사용자 신뢰를 회복하는 것은 매우 어려운 일이다. 보안 침해 사고는 고객 이탈을 초래하고, 브랜드 가치를 떨어뜨리며, 장기적인 영업 손실로 이어진다. 따라서 웹 보안은 단순한 기술 옵션이 아닌 서비스 운영의 필수 전제 조건이다.

개발 주기의 초기 단계부터 보안을 고려하는 시큐어 바이 디자인(Secure by Design) 접근 방식이 강조된다. 이는 문제 발생 후 대응하는 것보다 예방하는 것이 훨씬 효율적이고 비용이 적게 들기 때문이다. 보안은 백엔드 API 설계, 프론트엔드 코드 작성, 데이터베이스 관리, 네트워크 구성에 이르기까지 모든 계층에서 통합적으로 적용되어야 한다. 최종 사용자에게는 보이지 않지만, 웹 보안은 디지털 세계의 신뢰를 유지하는 보이지 않는 기반이 된다.

웹 애플리케이션을 위협하는 주요 공격 유형은 다양하게 존재한다. 가장 대표적인 것으로 크로스 사이트 스크립팅(XSS)을 들 수 있다. 이 공격은 악의적인 스크립트를 웹 페이지에 삽입하여 다른 사용자의 브라우저에서 실행되도록 한다. 이를 통해 공격자는 사용자의 세션 쿠키를 탈취하거나, 악성 사이트로 리다이렉트 시키는 등의 피해를 입힐 수 있다.

또 다른 심각한 위협은 SQL 인젝션이다. 이 공격은 애플리케이션의 데이터베이스 쿼리에 악의적인 SQL 코드를 삽입하여 데이터를 조작하거나 유출한다. 데이터베이스에 저장된 모든 사용자 정보, 비밀번호 해시, 중요한 비즈니스 데이터가 노출될 위험이 있다.

크로스 사이트 요청 위조(CSRF)는 사용자가 의도하지 않은 요청을 웹 애플리케이션에 전송하도록 속이는 공격이다. 사용자가 인증된 상태에서 악성 링크를 클릭하거나 악성 사이트를 방문하면, 공격자는 사용자의 권한으로 은행 이체나 비밀번호 변경 같은 행위를 서버에 요청할 수 있다.

이 외에도 클릭재킹, 서버 사이드 요청 위조(SSRF), 보안 설정 오류 등 다양한 위협이 존재한다. 각 공격 벡터는 서로 다른 방식으로 애플리케이션의 기밀성, 무결성, 가용성을 훼손한다. 따라서 이러한 위협 유형을 정확히 이해하는 것은 효과적인 방어 전략을 수립하는 첫걸음이다.

CORS(Cross-Origin Resource Sharing)는 웹 애플리케이션이 동일 출처 정책(Same-Origin Policy)을 우회하여 안전하게 교차 출처 HTTP 요청을 할 수 있도록 허용하는 메커니즘이다. 이 정책은 기본적으로 웹 브라우저가 보안상의 이유로 다른 출처(Origin)의 리소스 요청을 제한하는 것을 완화한다. 출처는 프로토콜, 호스트, 포트의 조합으로 정의된다[2]. CORS는 서버가 클라이언트(브라우저)에게 특정 출처에서 자신의 리소스에 접근할 수 있는 권한을 명시적으로 부여할 수 있는 방법을 제공한다.

CORS의 동작 원리는 브라우저와 서버 간의 협상을 통해 이루어진다. 브라우저가 교차 출처 요청을 보낼 때, 서버의 응답 헤더에 특정 CORS 관련 헤더(예: Access-Control-Allow-Origin)가 포함되어 있지 않으면, 브라우저는 해당 응답을 차단하고 자바스크립트 코드에 노출시키지 않는다. 이 과정은 단순 요청(Simple Request)과 프리플라이트 요청(Preflight Request) 두 가지 주요 방식으로 구분된다.

프리플라이트 요청에서 서버는 OPTIONS 요청에 대해 허용하는 출처, 메서드, 헤더 등을 응답 헤더로 알려준다. 브라우저는 이 정보를 검증한 후에만 실제 본 요청을 전송한다. 이렇게 두 단계로 나뉜 검증 과정을 통해, 서버는 자신의 리소스에 대한 교차 출처 접근을 세밀하게 통제할 수 있다.

• MDN Web Docs - CORS (교차 출처 리소스 공유)

• OWASP 한국어 - 웹 애플리케이션 보안 가이드

• Google Developers - 웹 보안 기본 사항

• Wikipedia - Cross-origin resource sharing

• W3C - Cross-Origin Resource Sharing

• 나무위키 - CORS

• HTTP 완벽 가이드 - 교차 출처 공유와 보안

• Microsoft Learn - CORS 해결 방법

CORS 오류는 주로 브라우저가 교차 출처 HTTP 요청을 차단할 때 발생하며, 콘솔에 표시되는 메시지와 HTTP 상태 코드를 통해 유형을 구분할 수 있다.

가장 흔한 오류는 서버의 응답 헤더에 Access-Control-Allow-Origin이 없거나, 요청한 출처(Origin)가 허용 목록에 포함되지 않은 경우다. 이때 브라우저 콘솔에는 "No 'Access-Control-Allow-Origin' header is present on the requested resource" 또는 "Origin ... is not allowed by Access-Control-Allow-Origin"과 같은 메시지가 표시된다. 사전 요청(Preflight Request)인 OPTIONS 메서드가 실패할 경우에도 유사한 오류가 발생한다.

다른 주요 오류 유형은 다음과 같다.

이러한 오류는 모두 브라우저의 동일 출처 정책(Same-Origin Policy)을 보완하는 CORS 메커니즘이 정상적으로 협상되지 못했음을 의미한다. 오류 메시지와 상태 코드(주로 403 Forbidden을 동반함)를 정확히 확인하는 것이 문제 해결의 첫 단계이다.

브라우저는 교차 출처 리소스 공유 요청이 발생할 때, 서버로의 실제 요청을 보내기 전에 먼저 프리플라이트 요청을 전송하여 안전성을 검증합니다. 이는 서버가 해당 출처와 메서드를 허용하는지 확인하기 위한 사전 점검 절차입니다. 프리플라이트 요청은 OPTIONS 메서드를 사용하며, Access-Control-Request-Method와 Access-Control-Request-Headers 헤더를 포함하여 실제 요청의 상세 정보를 서버에 알립니다.

서버는 이 프리플라이트 요청에 응답하여 허용 정책을 명시합니다. 응답 헤더에는 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 포함됩니다. 브라우저는 이 응답을 분석하여 실제 요청의 출처, 메서드, 헤더가 모두 서버의 허용 목록에 포함되어 있는지 검사합니다. 검증에 실패하면 브라우저는 실제 요청을 전송하지 않고 콘솔에 CORS 오류를 표시합니다.

모든 검증을 통과하면 브라우저는 최종 응답 데이터를 자바스크립트에 노출시킵니다. 단, 단순 요청의 경우 이 과정이 생략되고 바로 실제 요청이 전송됩니다[4]. 이 검증 과정은 동일 출처 정책을 우회하면서도 안전한 교차 출처 통신을 보장하는 핵심 메커니즘입니다.

CORS 문제를 해결하는 가장 근본적이고 권장되는 방법은 백엔드 서버에서 적절한 HTTP 응답 헤더를 설정하는 것이다. 이는 브라우저가 교차 출처 요청을 허용하도록 명시적으로 지시하는 역할을 한다.

핵심 헤더는 Access-Control-Allow-Origin이다. 이 헤더의 값으로 요청을 허용할 출처(Origin)를 지정한다. 모든 출처를 허용하려면 *를 값으로 설정할 수 있지만, 이는 보안상 위험할 수 있다. 특정 출처만 허용하려면 https://example.com과 같이 정확한 출처를 명시한다. 여러 출처를 동적으로 처리해야 하는 경우, 요청의 Origin 헤더를 검사하여 허용 목록에 있는 출처라면 그 값을 Access-Control-Allow-Origin 응답 헤더 값으로 그대로 반환하는 로직을 구현한다.

다른 중요한 CORS 관련 헤더들은 다음과 같다.

실제 요청 전에 브라우저가 보내는 프리플라이트 요청(Preflight Request, OPTIONS 메서드)에 대해서도 서버는 이러한 CORS 헤더를 포함한 응답을 반환해야 한다. 대부분의 현대 웹 프레임워크는 이러한 설정을 간편하게 할 수 있는 미들웨어나 라이브러리(예: Node.js의 cors 패키지, Spring의 @CrossOrigin 어노테이션)를 제공한다.

프록시 서버는 클라이언트와 다른 출처의 서버 사이에서 중계 역할을 하여 CORS 정책을 우회하는 데 활용할 수 있다. 클라이언트(예: 웹 브라우저)는 동일 출처인 프록시 서버에 요청을 보내고, 프록시 서버는 실제 목적지 서버에 대신 요청을 전달하여 응답을 받은 후 클라이언트에게 돌려준다. 이 과정에서 브라우저는 프록시 서버와의 통신만을 인식하므로, 동일 출처 정책에 위배되지 않는다.

프록시 서버를 구현하는 방식은 크게 두 가지로 나뉜다. 첫째는 개발 서버에 내장된 프록시 기능을 사용하는 것이다. 예를 들어, Create React App이나 Vite와 같은 현대적인 프론트엔드 도구는 vite.config.js 또는 package.json에 간단한 설정을 추가하여 특정 경로의 API 요청을 개발 중인 로컬 서버가 아닌 다른 백엔드 서버로 전달하도록 구성할 수 있다. 둘째는 Nginx나 Apache HTTP Server와 같은 독립적인 웹 서버 소프트웨어를 리버스 프록시로 구성하는 방법이다. 이는 주로 프로덕션 환경에서 사용되며, 클라이언트 요청을 적절한 백엔드 서비스로 라우팅하는 역할을 한다.

프록시 서버를 활용할 때는 보안 측면을 반드시 고려해야 한다. 모든 출처의 요청을 무조건 프록시하도록 설정하면, 프록시 서버 자체가 공격 벡터가 될 수 있다. 따라서 신뢰할 수 있는 특정 경로나 도메인으로의 요청만을 프록시하도록 제한하는 설정이 필요하다. 또한, 프록시 서버를 통한 통신에서도 민감한 자격 증명(Credentials)이나 세션 쿠키가 전달된다면, 해당 통신 채널 역시 HTTPS를 통해 암호화되어야 한다.

이 방법은 서버 측의 Access-Control-Allow-Origin 헤더를 수정할 수 없는 서드파티 API를 호출해야 할 때, 또는 여러 백엔드 서비스에 대한 요청을 하나의 진입점으로 통합하고자 할 때 유용하다. 그러나 이는 CORS 정책을 '회피'하는 기술일 뿐, 근본적인 해결책이 아니라는 점을 인지해야 한다. 보안상의 이점을 제공하는 동일 출처 정책을 우회하는 것이므로, 프록시 서버의 구성과 관리에 각별한 주의가 요구된다.

개발 단계에서는 CORS 정책으로 인한 제약이 작업 효율을 저하시킬 수 있다. 이를 우회하기 위한 몇 가지 임시적인 방법이 존재하지만, 이는 프로덕션 환경에서는 절대 사용해서는 안 된다는 점을 명심해야 한다.

가장 흔한 방법은 브라우저의 보안 기능을 일시적으로 비활성화하는 것이다. 크롬 브라우저의 경우 --disable-web-security 플래그를 사용하여 실행할 수 있다. 예를 들어 명령줄에서 chrome.exe --disable-web-security --user-data-dir="C:\TempChrome"과 같이 실행한다. 이 방법은 모든 동일 출처 정책 검사를 무시하므로, 신뢰할 수 없는 사이트를 방문할 경우 심각한 보안 위험에 노출된다. 파이어폭스에서는 about:config 설정에서 security.fileuri.strict_origin_policy 값을 false로 변경하는 방법이 있다.

다른 접근법으로는 브라우저 확장 프로그램을 설치하는 방법이 있다. "CORS Unblock" 또는 "Allow CORS: Access-Control-Allow-Origin"과 같은 확장 프로그램은 요청 헤더를 수정하여 CORS 오류를 우회한다. 이 방법 역시 보안 취약점을 만들어낼 수 있으며, 확장 프로그램 자체의 신뢰성을 확인해야 한다.

로컬 개발 서버를 구성할 때는 Node.js 기반의 간단한 프록시 서버를 활용하는 것이 더 안전한 대안이다. http-proxy-middleware나 cors-anywhere와 같은 패키지를 사용하면, 로컬에서 실행되는 프록시가 API 요청을 중계하여 브라우저의 보안 정책을 위반하지 않으면서 문제를 해결한다. 이 방법은 실제 서버 측 CORS 설정을 테스트하는 데에도 유용하다.

• MDN Web Docs - CORS (Cross-Origin Resource Sharing)

• OWASP 한국어 - 웹 애플리케이션 보안 가이드

• Google Developers - 웹 보안 기본 사항

• 위키백과 - 교차 출처 리소스 공유

• NHN Cloud - CORS는 왜 이렇게 우리를 힘들게 하는걸까?

• W3C - Cross-Origin Resource Sharing (CORS) Specification

• Microsoft Learn - CORS 해결 방법

• MDN Web Docs - HTTP 접근 제어 (CORS)

CORS 요청 시 자격 증명(쿠키, HTTP 인증, 클라이언트 측 SSL 인증서 등)을 포함하려면 클라이언트와 서버 모두 명시적인 설정이 필요합니다. 클라이언트는 XMLHttpRequest나 fetch API를 사용할 때 withCredentials 속성을 true로 설정하거나 credentials: 'include' 옵션을 지정해야 합니다. 이 설정이 없으면 브라우저는 교차 출처 요청에 자격 증명을 첨부하지 않으며, 서버에서 설정한 관련 쿠키도 전송되지 않습니다.

서버 측에서는 자격 증명을 허용하는 CORS 응답 헤더를 보다 엄격하게 설정해야 합니다. Access-Control-Allow-Origin 헤더의 값은 와일드카드(*)가 될 수 없으며, 요청을 보내는 정확한 출처(origin)를 명시해야 합니다. 동시에 Access-Control-Allow-Credentials: true 헤더를 반드시 포함시켜 응답해야 합니다. 이 두 조건이 모두 충족되지 않으면 브라우저는 자격 증명이 포함된 요청에 대한 응답을 차단하고 CORS 오류를 발생시킵니다.

자격 증명을 허용하는 CORS 정책을 구성할 때는 보안에 특별히 주의해야 합니다. Access-Control-Allow-Origin을 와일드카드(*)로 설정하는 것은 허용되지 않으므로, 서버는 신뢰할 수 있는 출처 목록을 동적으로 검증하거나 구성 파일에서 관리하는 방식으로 엄격하게 제한해야 합니다. 또한, 민감한 정보를 다루는 요청의 경우 Access-Control-Allow-Methods와 Access-Control-Allow-Headers도 필요한 최소 범위로 제한하는 것이 좋습니다.

CSP(Content Security Policy)는 XSS(교차 사이트 스크립팅) 공격과 같은 특정 유형의 웹 기반 공격을 완화하기 위해 설계된 보안 계층이다. 웹 개발자가 브라우저가 해당 페이지에 대해 로드할 수 있는 리소스(스크립트, 이미지, 스타일시트 등)의 출처를 제어할 수 있게 해준다. 정책은 서버가 Content-Security-Policy HTTP 헤더를 통해 브라우저에 전달하며, 이 헤더에 명시된 규칙에 따라 브라우저는 콘텐츠를 제한적으로 로드한다.

CSP는 여러 지시어(directive)를 통해 세부적인 제어를 제공한다. 주요 지시어로는 default-src, script-src, style-src, img-src, connect-src, font-src, object-src, frame-src 등이 있다. 예를 들어, script-src 'self' https://trusted.cdn.com;과 같이 설정하면, 스크립트는 동일 출처('self')와 명시된 CDN 도메인에서만 로드할 수 있다. 'unsafe-inline'이나 'unsafe-eval'과 같은 키워드를 허용하면 보안성이 낮아지므로 신중하게 사용해야 한다.

CSP를 효과적으로 구현하기 위해서는 보고서(reporting) 기능을 활용하는 것이 좋다. Content-Security-Policy-Report-Only 헤더를 사용하면 정책을 시행하지 않고 위반 사항만 지정된 URI로 보고받을 수 있다. 이를 통해 실제 서비스에 적용하기 전에 정책이 기존 기능을 방해하지 않는지 검증할 수 있다. 또한 report-uri 또는 report-to 지시어를 사용하여 위반 사항을 지속적으로 모니터링할 수 있다.

CSP는 CORS와 상호 보완적인 역할을 한다. CORS가 다른 출처의 리소스 요청 자체를 제어하는 메커니즘이라면, CSP는 리소스가 로드된 후에도 해당 리소스가 수행할 수 있는 행동(예: 인라인 스크립트 실행)을 제한한다. 따라서 두 기술을 함께 적용하면 웹 애플리케이션의 보안 수준을 종합적으로 높일 수 있다.

JWT(JSON Web Tokens)는 당사자 간에 정보를 JSON 객체로 안전하게 전송하기 위한 개방형 표준(RFC 7519)이다. 이 토큰은 디지털 서명되어 있어 신뢰할 수 있으며, 주로 인증(Authentication)과 권한 부여(Authorization) 목적으로 사용된다. JWT는 헤더, 페이로드, 서명의 세 부분으로 구성되며, 각 부분은 점(.)으로 구분된다. 서명은 토큰의 무결성을 보장하고, 페이로드에는 사용자에 대한 클레임(정보)이 포함되어 발급자가 누구인지와 접근 권한을 확인하는 데 사용된다.

웹 애플리케이션에서 JWT는 주로 세션 기반 인증을 대체하는 토큰 기반 인증 방식으로 활용된다. 사용자가 로그인하면 서버는 인증 정보를 검증하고 JWT를 생성하여 클라이언트에 반환한다. 이후 클라이언트는 이 토큰을 HTTP 요청의 Authorization 헤더에 담아 서버에 보내고, 서버는 토큰의 서명을 검증하여 요청의 유효성을 확인한다. 이 방식은 서버가 사용자 상태를 저장할 필요가 없는 무상태(Stateless) 아키텍처를 가능하게 하여 확장성을 높인다.

JWT는 CORS 정책과 밀접한 관련이 있다. 다른 출처(Origin)로 API 요청을 보낼 때, 인증이 필요한 요청은 자격 증명(쿠키, 인증 헤더 등)을 포함해야 한다. 이때 서버의 CORS 설정에서 Access-Control-Allow-Credentials: true를 허용하고, Access-Control-Allow-Origin 헤더에 와일드카드(*)가 아닌 구체적인 출처를 명시해야 JWT를 안전하게 주고받을 수 있다. JWT 자체는 일반적으로 로컬 스토리지나 세션 스토리지에 저장되므로, XSS(Cross-Site Scripting) 공격에 노출될 위험성이 있다는 점을 보안 설계 시 고려해야 한다.

Node.js와 Express 프레임워크를 사용하여 CORS 정책을 설정하는 방법은 크게 두 가지로 나뉜다. 첫 번째는 cors 미들웨어 패키지를 사용하는 것이고, 두 번째는 수동으로 응답 헤더를 설정하는 방법이다. cors 패키지는 가장 일반적이고 간편한 방법으로, npm을 통해 설치하여 사용한다.

cors 패키지를 기본 설정으로 적용하려면, 애플리케이션의 진입점 파일에서 미들웨어로 등록하면 된다. 이렇게 하면 모든 도메인에서의 요청을 허용하는 Access-Control-Allow-Origin: * 헤더가 설정된다. 하지만 이는 보안상 취약할 수 있으므로, 실제 운영 환경에서는 특정 출처만 허용하도록 구성하는 것이 바람직하다. 패키지의 옵션을 사용하여 허용할 출처, 메서드, 헤더 등을 세밀하게 제어할 수 있다.

보다 세부적인 설정을 위한 예제 코드는 다음과 같다. 이 설정은 특정 출처만 허용하며, 자격 증명을 포함한 요청을 받고, 몇 가지 특정 HTTP 메서드와 헤더를 허용한다.

```javascript

const express = require('express');

const cors = require('cors');

const app = express();

const corsOptions = {

origin: 'https://trusted-client.com', // 허용할 출처. 배열로 여러 개 지정 가능

credentials: true, // 쿠키 등의 자격 증명 허용

optionsSuccessStatus: 200, // 일부 레거시 브라우저를 위한 상태 코드

allowedHeaders: ['Content-Type', 'Authorization'], // 허용할 요청 헤더

methods: ['GET', 'POST', 'PUT', 'DELETE'] // 허용할 HTTP 메서드

};

app.use(cors(corsOptions));

// 라우트 정의

app.get('/data', (req, res) => {

res.json({ message: 'CORS가 설정된 데이터' });

});

app.listen(3000, () => {

console.log('서버가 3000번 포트에서 실행 중입니다.');

});

```

cors 패키지를 사용하지 않고 수동으로 헤더를 설정하는 방법도 있다. 이는 매우 간단한 경우나, 미들웨어의 동작을 완전히 제어해야 할 때 유용하다. 다음은 사용자 정의 미들웨어 함수를 작성하여 특정 출처에 대해 CORS 헤더를 추가하는 예시이다. 그러나 복잡한 요청(Preflight 요청)을 완전히 처리하려면 추가 로직이 필요하므로, 일반적으로는 cors 패키지 사용을 권장한다.

Spring Boot 애플리케이션에서 CORS 정책을 구성하는 방법은 주로 설정 파일을 이용하거나, Java Configuration 클래스를 정의하거나, 어노테이션을 사용하는 방식이 있다. 가장 일반적인 방법은 전역 설정을 위한 WebMvcConfigurer 인터페이스를 구현하는 Configuration 클래스를 생성하는 것이다. 이 클래스 내에서 addCorsMappings 메서드를 재정의하여 허용할 오리진, HTTP 메서드, 헤더, 자격 증명 전송 여부 등을 세부적으로 지정할 수 있다.

특정 컨트롤러나 메서드에만 CORS 정책을 적용하려면 @CrossOrigin 어노테이션을 사용한다. 이 어노테이션은 메서드 또는 클래스 수준에서 적용 가능하며, origins, methods, allowedHeaders, allowCredentials 등의 속성을 통해 제어한다. 예를 들어, @CrossOrigin(origins = "https://trusted-domain.com")과 같이 작성하면 해당 엔드포인트는 지정된 출처의 요청만 허용한다.

보다 세밀한 제어가 필요하거나 서블릿 필터 수준에서 처리해야 할 경우, CorsFilter 빈을 직접 구성할 수 있다. 이 방법은 CorsConfigurationSource를 설정하고, 허용할 출처, 메서드, 헤더를 리스트 형태로 명시적으로 정의하는 방식으로, 가장 강력하고 유연한 설정이 가능하다. 모든 설정에서 보안을 위해 allowedOrigins에는 와일드카드(*)보다는 신뢰할 수 있는 구체적인 도메인을 명시하는 것이 권장되며, 자격 증명(allowCredentials)을 사용할 경우 출처 지정은 반드시 필요하다.