프런트엔드 보안 강화: 콘텐츠 보안 정책(CSP)과 CORS

오늘날과 같이 상호 연결된 디지털 환경에서 프런트엔드 보안은 무엇보다 중요합니다. 웹 애플리케이션은 점점 더 정교한 공격의 대상이 되고 있어 강력한 보안 조치가 필수적입니다. 안전한 프런트엔드 아키텍처의 두 가지 중요한 구성 요소는 콘텐츠 보안 정책(CSP)과 교차 출처 리소스 공유(CORS)입니다. 이 종합 가이드에서는 이러한 기술을 심층적으로 살펴보고, 최신 위협으로부터 웹 애플리케이션을 강화하는 데 도움이 되는 실용적인 예제와 실행 가능한 통찰력을 제공합니다.

콘텐츠 보안 정책(CSP)이란 무엇인가?

콘텐츠 보안 정책(CSP)은 크로스 사이트 스크립팅(XSS) 및 데이터 삽입 공격과 같은 특정 유형의 공격을 탐지하고 완화하는 데 도움이 되는 추가 보안 계층입니다. CSP는 웹 서버가 브라우저에 Content-Security-Policy HTTP 응답 헤더를 전송하여 구현됩니다. 이 헤더는 브라우저가 리소스를 로드할 수 있도록 허용된 소스의 허용 목록(whitelist)을 정의합니다. 브라우저가 로드할 수 있는 콘텐츠의 소스를 제한함으로써, CSP는 공격자가 웹사이트에 악성 코드를 삽입하는 것을 훨씬 더 어렵게 만듭니다.

CSP의 작동 방식

CSP는 브라우저에게 승인된 소스에서만 리소스(예: 스크립트, 스타일시트, 이미지, 폰트)를 로드하도록 지시하는 방식으로 작동합니다. 이러한 소스는 CSP 헤더의 지시어(directives)를 사용하여 지정됩니다. 브라우저가 명시적으로 허용되지 않은 소스에서 리소스를 로드하려고 하면, 해당 요청을 차단하고 위반 사항을 보고합니다.

CSP 지시어: 종합 개요

CSP 지시어는 특정 소스에서 로드할 수 있는 리소스의 유형을 제어합니다. 다음은 가장 중요한 지시어 중 일부에 대한 설명입니다:

• default-src: 모든 콘텐츠 유형에 대한 기본 소스를 지정합니다. 이는 다른 더 구체적인 지시어가 없을 때 적용되는 대체 지시어입니다.
• script-src: 스크립트를 로드할 수 있는 소스를 지정합니다. 이는 XSS 공격을 방지하는 데 매우 중요합니다.
• style-src: 스타일시트를 로드할 수 있는 소스를 지정합니다.
• img-src: 이미지를 로드할 수 있는 소스를 지정합니다.
• font-src: 폰트를 로드할 수 있는 소스를 지정합니다.
• media-src: 오디오 및 비디오를 로드할 수 있는 소스를 지정합니다.
• object-src: 플러그인(예: Flash)을 로드할 수 있는 소스를 지정합니다. 내재된 보안 위험 때문에 플러그인을 완전히 비활성화하기 위해 종종 'none'으로 설정됩니다.
• frame-src: 프레임(예: <iframe>)을 로드할 수 있는 소스를 지정합니다.
• connect-src: XMLHttpRequest, WebSocket, EventSource와 같은 스크립트 인터페이스를 사용하여 사용자 에이전트가 연결할 수 있는 URL을 지정합니다.
• base-uri: 문서의 <base> 요소에 사용할 수 있는 URL을 지정합니다.
• form-action: 폼 제출을 보낼 수 있는 URL을 지정합니다.
• upgrade-insecure-requests: 사용자 에이전트에게 안전하지 않은 요청(HTTP)을 안전한 요청(HTTPS)으로 자동 업그레이드하도록 지시합니다.
• report-uri: 브라우저가 CSP 위반에 대한 보고서를 보내야 하는 URL을 지정합니다. 이 지시어는 `report-to`를 위해 사용이 중단되었습니다.
• report-to: 브라우저가 CSP 위반에 대한 보고서를 보내야 하는 `Report-To` 헤더에 정의된 보고 그룹 이름을 지정합니다.

CSP 소스 목록 키워드

CSP 지시어 내에서 소스 목록 키워드를 사용하여 허용된 소스를 정의할 수 있습니다. 다음은 몇 가지 일반적인 키워드입니다:

• 'self': 문서와 동일한 출처(스키마 및 호스트)의 리소스를 허용합니다.
• 'none': 모든 소스의 리소스를 허용하지 않습니다.
• 'unsafe-inline': 인라인 스크립트 및 스타일(예: <script> 태그 및 style 속성)의 사용을 허용합니다. XSS에 대한 CSP 보호를 크게 약화시키므로 극도의 주의를 기울여 사용해야 합니다.
• 'unsafe-eval': eval() 및 Function()과 같은 동적 코드 평가 함수의 사용을 허용합니다. 상당한 보안 위험을 초래하므로 극도의 주의를 기울여 사용해야 합니다.
• 'unsafe-hashes': 지정된 해시와 일치하는 특정 인라인 이벤트 핸들러 또는 <style> 태그를 허용합니다. 브라우저 지원이 필요합니다. 주의해서 사용하십시오.
• 'strict-dynamic': 논스나 해시와 함께 마크업에 존재하는 스크립트에 명시적으로 부여된 신뢰가 해당 루트 스크립트에 의해 로드되는 모든 스크립트로 전파되어야 함을 지정합니다.
• data: data: URI(예: base64로 인코딩된 인라인 이미지)를 허용합니다. 주의해서 사용하십시오.
• https:: 모든 도메인에서 HTTPS를 통해 리소스를 로드할 수 있도록 허용합니다.
• [hostname]: 특정 도메인(예: example.com)의 리소스를 허용합니다. 포트 번호도 지정할 수 있습니다(예: example.com:8080).
• [scheme]://[hostname]:[port]: 정규화된 URI로, 지정된 스키마, 호스트 및 포트의 리소스를 허용합니다.

실용적인 CSP 예제

CSP 헤더의 몇 가지 실용적인 예제를 살펴보겠습니다:

예제 1: 'self'를 사용한 기본 CSP

이 정책은 동일한 출처의 리소스만 허용합니다:

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

              
                Copy
              
            
          

예제 2: 특정 도메인의 스크립트 허용

이 정책은 자신의 도메인과 신뢰할 수 있는 CDN의 스크립트를 허용합니다:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
            

              
                Copy
              
            
          

예제 3: 인라인 스크립트 및 스타일 비활성화

이 정책은 인라인 스크립트와 스타일을 허용하지 않으며, 이는 XSS에 대한 강력한 방어책입니다:

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

              
                Copy
              
            
          

중요: 인라인 스크립트를 비활성화하려면 인라인 스크립트를 외부 파일로 옮기도록 HTML을 리팩터링해야 합니다.

예제 4: 인라인 스크립트에 논스(Nonces) 사용

인라인 스크립트를 사용해야 하는 경우, 논스(암호학적으로 무작위이며 일회용인 토큰)를 사용하여 특정 인라인 스크립트 블록을 허용 목록에 추가하십시오. 이는 'unsafe-inline'보다 더 안전합니다. 서버는 각 요청에 대해 고유한 논스를 생성하고 CSP 헤더와 <script> 태그 모두에 포함해야 합니다.

            Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0mN0nc3'; style-src 'self'
            

              
                Copy
              
            
          

            <script nonce="r4nd0mN0nc3"> console.log('Inline script'); </script>
            

              
                Copy
              
            
          

참고: 각 요청마다 새로운 논스를 생성하는 것을 잊지 마십시오. 논스를 재사용하지 마십시오!

예제 5: 인라인 스타일에 해시(Hashes) 사용

논스와 유사하게, 해시를 사용하여 특정 인라인 <style> 블록을 허용 목록에 추가할 수 있습니다. 이는 스타일 콘텐츠의 SHA256, SHA384 또는 SHA512 해시를 생성하여 수행됩니다.

            Content-Security-Policy: default-src 'self'; style-src 'sha256-HASHEDSTYLES'
            

              
                Copy
              
            
          

            <style sha256="HASHEDSTYLES"> body { background-color: #f0f0f0; } </style>
            

              
                Copy
              
            
          

참고: 해시는 스타일 콘텐츠를 변경하면 해시가 무효화되므로 논스보다 유연성이 떨어집니다.

예제 6: CSP 위반 보고

CSP 위반을 모니터링하려면 report-uri 또는 report-to 지시어를 사용하십시오:

            Content-Security-Policy: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

또한 Report-To 헤더를 구성해야 합니다. Report-To 헤더는 보고서를 어디로 어떻게 보낼지 지정하는 하나 이상의 보고 그룹을 정의합니다.

            Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
            

              
                Copy
              
            
          

CSP 테스트 및 배포

CSP를 구현하려면 신중한 계획과 테스트가 필요합니다. 제한적인 정책으로 시작하여 필요에 따라 점차 완화하십시오. Content-Security-Policy-Report-Only 헤더를 사용하여 리소스를 차단하지 않고 정책을 테스트할 수 있습니다. 이 헤더는 정책을 강제하지 않고 위반 사항을 보고하므로, 프로덕션 환경에 정책을 배포하기 전에 문제를 식별하고 수정할 수 있습니다.

            Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

브라우저에서 생성된 보고서를 분석하여 위반 사항을 식별하고 그에 따라 정책을 조정하십시오. 정책이 올바르게 작동한다고 확신하면 Content-Security-Policy 헤더를 사용하여 배포하십시오.

CSP 모범 사례

• default-src로 시작하기: 항상 default-src를 정의하여 기준 정책을 설정하십시오.
• 구체적으로 지정하기: 특정 지시어와 소스 목록 키워드를 사용하여 정책의 범위를 제한하십시오.
• 'unsafe-inline' 및 'unsafe-eval' 피하기: 이 키워드들은 CSP를 크게 약화시키므로 가능한 한 피해야 합니다.
• 인라인 스크립트 및 스타일에 논스 또는 해시 사용하기: 인라인 스크립트나 스타일을 사용해야 하는 경우, 논스나 해시를 사용하여 특정 코드 블록을 허용 목록에 추가하십시오.
• CSP 위반 모니터링하기: report-uri 또는 report-to 지시어를 사용하여 CSP 위반을 모니터링하고 그에 따라 정책을 조정하십시오.
• 철저하게 테스트하기: 프로덕션 환경에 배포하기 전에 Content-Security-Policy-Report-Only 헤더를 사용하여 정책을 테스트하십시오.
• 반복 및 개선하기: CSP는 일회성 구성이 아닙니다. 애플리케이션 및 위협 환경의 변화에 적응하기 위해 지속적으로 정책을 모니터링하고 개선하십시오.

교차 출처 리소스 공유(CORS)란 무엇인가?

교차 출처 리소스 공유(CORS)는 한 출처(도메인)의 웹 페이지가 다른 출처의 리소스에 접근할 수 있도록 하는 메커니즘입니다. 기본적으로 브라우저는 동일 출처 정책(Same-Origin Policy)을 시행하여 스크립트가 시작된 출처와 다른 출처로 요청하는 것을 방지합니다. CORS는 이 제한을 선택적으로 완화하여 합법적인 교차 출처 요청을 허용하면서 악의적인 공격으로부터 보호하는 방법을 제공합니다.

동일 출처 정책(Same-Origin Policy) 이해하기

동일 출처 정책은 한 웹사이트의 악성 스크립트가 다른 웹사이트의 민감한 데이터에 접근하는 것을 방지하는 기본적인 보안 메커니즘입니다. 출처는 스키마(프로토콜), 호스트(도메인), 포트로 정의됩니다. 두 URL이 동일한 스키마, 호스트, 포트를 가질 때에만 동일한 출처를 갖습니다.

예를 들어:

• https://www.example.com/app1/index.html와 https://www.example.com/app2/index.html는 동일한 출처를 가집니다.
• https://www.example.com/index.html와 http://www.example.com/index.html는 다른 출처를 가집니다(다른 스키마).
• https://www.example.com/index.html와 https://sub.example.com/index.html는 다른 출처를 가집니다(다른 호스트).
• https://www.example.com:8080/index.html와 https://www.example.com:80/index.html는 다른 출처를 가집니다(다른 포트).

CORS의 작동 방식

웹 페이지가 교차 출처 요청을 할 때, 브라우저는 먼저 서버에 "프리플라이트(preflight)" 요청을 보냅니다. 프리플라이트 요청은 HTTP OPTIONS 메서드를 사용하며, 실제 요청이 사용할 HTTP 메서드와 헤더를 나타내는 헤더를 포함합니다. 그러면 서버는 교차 출처 요청이 허용되는지 여부를 나타내는 헤더로 응답합니다.

서버가 요청을 허용하면 응답에 Access-Control-Allow-Origin 헤더를 포함합니다. 이 헤더는 리소스에 접근할 수 있는 출처를 지정합니다. 그러면 브라우저는 실제 요청을 진행합니다. 서버가 요청을 허용하지 않으면 Access-Control-Allow-Origin 헤더를 포함하지 않으며 브라우저는 요청을 차단합니다.

CORS 헤더: 자세히 살펴보기

CORS는 브라우저와 서버 간의 통신을 위해 HTTP 헤더에 의존합니다. 다음은 주요 CORS 헤더입니다:

• Access-Control-Allow-Origin: 리소스에 접근이 허용된 출처를 지정합니다. 이 헤더는 특정 출처(예: https://www.example.com), 와일드카드(*) 또는 null을 포함할 수 있습니다. *를 사용하면 모든 출처의 요청을 허용하므로 보안상의 이유로 일반적으로 권장되지 않습니다. `null`은 리소스가 `file://` 프로토콜이나 데이터 URI를 사용하여 검색될 때와 같은 "불투명한 응답"에만 적합합니다.
• Access-Control-Allow-Methods: 교차 출처 요청에 허용되는 HTTP 메서드(예: GET, POST, PUT, DELETE)를 지정합니다.
• Access-Control-Allow-Headers: 교차 출처 요청에 허용되는 HTTP 헤더를 지정합니다. 이는 사용자 지정 헤더를 처리하는 데 중요합니다.
• Access-Control-Allow-Credentials: 브라우저가 교차 출처 요청에 자격 증명(예: 쿠키, 인증 헤더)을 포함해야 하는지 여부를 나타냅니다. 자격 증명을 허용하려면 이 헤더를 true로 설정해야 합니다.
• Access-Control-Expose-Headers: 클라이언트에 노출될 수 있는 헤더를 지정합니다. 기본적으로 제한된 헤더 집합만 노출됩니다.
• Access-Control-Max-Age: 브라우저가 프리플라이트 요청을 캐시할 수 있는 최대 시간(초)을 지정합니다.
• Origin: 브라우저가 요청의 출처를 나타내기 위해 보내는 요청 헤더입니다.
• Vary: 일반적인 HTTP 헤더이지만 CORS에 중요합니다. `Access-Control-Allow-Origin`이 동적으로 생성될 때, 응답이 `Origin` 요청 헤더에 따라 달라진다는 것을 캐싱 메커니즘에 지시하기 위해 `Vary: Origin` 헤더를 응답에 포함해야 합니다.

실용적인 CORS 예제

CORS 구성의 몇 가지 실용적인 예제를 살펴보겠습니다:

예제 1: 특정 출처의 요청 허용

이 구성은 https://www.example.com의 요청만 허용합니다:

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

예제 2: 모든 출처의 요청 허용 (권장하지 않음)

이 구성은 모든 출처의 요청을 허용합니다. 보안 위험을 초래할 수 있으므로 주의해서 사용하십시오:

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

예제 3: 특정 메서드 및 헤더 허용

이 구성은 GET, POST, PUT 메서드와 Content-Type, Authorization 헤더를 허용합니다:

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

예제 4: 자격 증명 허용

자격 증명(예: 쿠키)을 허용하려면 Access-Control-Allow-Credentials를 true로 설정하고 특정 출처를 지정해야 합니다 (자격 증명을 허용할 때는 *를 사용할 수 없습니다):

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

또한 JavaScript fetch/XMLHttpRequest 요청에서 credentials: 'include'를 설정해야 합니다.

            fetch('https://api.example.com/data', {
  credentials: 'include'
})
            

              
                Copy
              
            
          

CORS 프리플라이트(Preflight) 요청

특정 유형의 교차 출처 요청(예: 사용자 지정 헤더가 있는 요청 또는 GET, HEAD 또는 POST(Content-Type이 application/x-www-form-urlencoded, multipart/form-data 또는 text/plain인 경우) 이외의 메서드를 사용하는 요청)의 경우 브라우저는 OPTIONS 메서드를 사용하여 프리플라이트 요청을 보냅니다. 서버는 프리플라이트 요청에 적절한 CORS 헤더로 응답하여 실제 요청이 허용되는지 여부를 나타내야 합니다.

다음은 프리플라이트 요청 및 응답의 예입니다:

프리플라이트 요청 (OPTIONS):

            OPTIONS /data HTTP/1.1
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

프리플라이트 응답 (200 OK):

            HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
            

              
                Copy
              
            
          

Access-Control-Max-Age 헤더는 브라우저가 프리플라이트 응답을 캐시할 수 있는 기간을 지정하여 프리플라이트 요청 수를 줄입니다.

CORS와 JSONP

JSON with Padding (JSONP)는 동일 출처 정책을 우회하기 위한 오래된 기술입니다. 그러나 JSONP는 상당한 보안 위험이 있으므로 CORS를 선호하여 피해야 합니다. JSONP는 페이지에 <script> 태그를 주입하는 것에 의존하며, 이는 임의의 코드를 실행할 수 있습니다. CORS는 교차 출처 요청을 처리하는 더 안전하고 유연한 방법을 제공합니다.

CORS 모범 사례

• * 사용 피하기: Access-Control-Allow-Origin 헤더에서 와일드카드(*) 사용을 피하십시오. 이는 모든 출처의 요청을 허용합니다. 대신 리소스에 접근이 허용된 특정 출처를 지정하십시오.
• 메서드 및 헤더를 구체적으로 지정하기: Access-Control-Allow-Methods 및 Access-Control-Allow-Headers 헤더에 허용되는 정확한 HTTP 메서드와 헤더를 지정하십시오.
• Access-Control-Allow-Credentials 주의해서 사용하기: 교차 출처 요청에서 자격 증명(예: 쿠키)을 허용해야 하는 경우에만 Access-Control-Allow-Credentials를 활성화하십시오. 자격 증명 허용의 보안적 영향을 인지하십시오.
• 프리플라이트 요청 보안하기: 서버가 프리플라이트 요청을 올바르게 처리하고 정확한 CORS 헤더를 반환하는지 확인하십시오.
• HTTPS 사용하기: 출처와 교차 출처로 접근하는 리소스 모두에 항상 HTTPS를 사용하십시오. 이는 중간자 공격으로부터 보호하는 데 도움이 됩니다.
• Vary: Origin: `Access-Control-Allow-Origin` 헤더를 동적으로 생성하는 경우, 캐싱 문제를 방지하기 위해 항상 `Vary: Origin` 헤더를 포함하십시오.

실무에서의 CSP와 CORS: 결합된 접근 방식

CSP와 CORS는 모두 보안 문제를 다루지만, 서로 다른 계층에서 작동하며 상호 보완적인 보호를 제공합니다. CSP는 브라우저가 악성 콘텐츠를 로드하는 것을 방지하는 데 중점을 두는 반면, CORS는 서버의 리소스에 어떤 출처가 접근할 수 있는지 제어하는 데 중점을 둡니다.

CSP와 CORS를 결합하면 웹 애플리케이션에 대한 더 강력한 보안 태세를 구축할 수 있습니다. 예를 들어, CSP를 사용하여 스크립트를 로드할 수 있는 소스를 제한하고, CORS를 사용하여 API 엔드포인트에 접근할 수 있는 출처를 제어할 수 있습니다.

예제: CSP와 CORS로 API 보안하기

https://api.example.com에 호스팅된 API가 https://www.example.com에서만 접근 가능하도록 하려면, 서버가 다음 헤더를 반환하도록 구성할 수 있습니다:

API 응답 헤더 (https://api.example.com):

            Access-Control-Allow-Origin: https://www.example.com
Content-Type: application/json
            

              
                Copy
              
            
          

그리고 웹사이트(https://www.example.com)가 다음 CSP 헤더를 사용하도록 구성할 수 있습니다:

웹사이트 CSP 헤더 (https://www.example.com):

            Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self' https://api.example.com;
            

              
                Copy
              
            
          

이 CSP 정책은 웹사이트가 스크립트를 로드하고 API에 연결하는 것을 허용하지만, 다른 도메인에서 스크립트를 로드하거나 연결하는 것은 방지합니다.

결론

콘텐츠 보안 정책(CSP)과 교차 출처 리소스 공유(CORS)는 프런트엔드 애플리케이션의 보안을 강화하는 데 필수적인 도구입니다. CSP와 CORS를 신중하게 구성함으로써 XSS 공격, 데이터 삽입 공격 및 기타 보안 취약점의 위험을 크게 줄일 수 있습니다. 제한적인 정책으로 시작하고, 철저히 테스트하며, 애플리케이션 및 진화하는 위협 환경의 변화에 적응하기 위해 구성을 지속적으로 모니터링하고 개선하는 것을 기억하십시오. 프런트엔드 보안을 우선시함으로써 사용자를 보호하고 오늘날 점점 더 복잡해지는 디지털 세계에서 웹 애플리케이션의 무결성을 보장할 수 있습니다.