Flask XSS 보안 가이드, 자동 이스케이프와 Content Security Policy 설정으로 안전한 파이썬 웹 만들기

Flask XSS 보안 가이드, 자동 이스케이프와 Content Security Policy 설정으로 안전한 파이썬 웹 만들기

🛡️ 사용자가 입력한 스크립트가 그대로 실행되는 걸 막으려면 Flask에서 어떤 보안 설정을 꼭 켜야 할까요?

Flask로 웹 서비스를 만들다 보면 로그인 폼이나 댓글, 검색창처럼 사용자가 직접 텍스트를 입력하는 부분이 정말 많습니다.
겉으로 보기엔 그냥 문자열인데, 이 입력값이 브라우저에서 그대로 실행 가능한 스크립트 형태로 출력되면 문제가 완전히 달라집니다.
자바스크립트가 삽입돼서 다른 사용자 세션을 가로채거나, 쿠키를 빼가거나, 페이지 내용을 조작할 수 있는 공격이 가능한데 이런 공격을 XSS (Cross-Site Scripting)이라고 부릅니다.
현실적으로 XSS는 웹 공격 중에 가장 자주 언급되는 취약점이고, Flask처럼 서버에서 템플릿을 렌더링해 HTML을 내려주는 구조에서도 충분히 발생할 수 있습니다.
특히 팀 개발을 하다 보면 “이 값은 신뢰 가능한 값이야”라며 필터를 빼거나, 디자이너 요청으로 편하게 하려고 인라인 스크립트를 허용하는 경우가 한두 번씩 생기는데, 바로 그 부분이 쉽게 노출되는 지점이 됩니다.

Flask는 기본적으로 Jinja2 템플릿 엔진을 쓰는데, 다행히 자동 이스케이프(autoescaping)라는 기능 덕분에 사용자 입력을 그대로 HTML로 해석하지 않도록 막아줍니다.
Flask의 render_template()로 .html, .htm, .xml, .xhtml, .svg 같은 확장자의 템플릿을 렌더링하면 기본적으로 자동 이스케이프가 활성화됩니다.
즉 사용자가 <script>alert(1)</script> 라고 입력해도, 실제로는 문자 그대로 브라우저에 전달되도록 처리되어 실행되지 않게 됩니다.
문제는 개발자가 무심코 이 보호 장치를 끄거나(autoescape=False), 특정 부분만 “safe” 처리해서 신뢰되지 않은 값을 HTML로 직접 뿌려버릴 때인데, 이건 고전적인 XSS 취약점으로 이어집니다.

또 하나 반드시 짚고 넘어가야 할 게 Content Security Policy (CSP)입니다.
CSP는 브라우저에게 “이 사이트에서는 어떤 자바스크립트, 어떤 스타일, 어떤 리소스만 허용할지”를 선언하는 보안 헤더인데, 쉽게 말해 허가된 소스 외에서 온 스크립트는 전부 차단해라라고 지시하는 장치입니다.
요즘 권장되는 방식은 nonce(요청마다 서버가 랜덤하게 생성하는 일회성 토큰)나 해시 기반 정책을 써서, 그 nonce 또는 해시 값이 붙은 스크립트만 실행하도록 하는 Strict CSP 전략입니다.
이렇게 하면 설령 HTML 주입이 somehow 성공하더라도 공격자가 마음대로 자바스크립트를 실행시키기 훨씬 어려워집니다.
결국 Flask 보안의 핵심 축은 세 가지로 모일 수 있습니다.
입력값을 그대로 실행되지 않게 막는 템플릿 자동 이스케이프.
브라우저 단에서 승인된 스크립트만 동작하게 만드는 CSP.
그리고 개발자 스스로 “이건 괜찮겠지?”라고 가정하지 않는 습관입니다.

이 글은 Flask에서 자주 놓치는 XSS 취약점의 기본 원리부터, Jinja2 자동 이스케이프를 어떻게 안전하게 유지해야 하는지, CSP 헤더를 어떻게 설정해야 실제로 도움이 되는지까지 순서대로 풀어보려고 합니다.
한마디로 말해서, “사용자 입력이 곧 공격 벡터”라는 전제를 가지고 Flask 앱을 방어하는 실전 관점입니다.
웹 서비스를 운영 중이라면 지금 코드에 바로 적용할 만한 내용들도 포함되어 있으니 보안 점검 겸 체크리스트처럼 읽어도 충분합니다.

🛡️ Flask에서 XSS는 왜 위험한가

웹 애플리케이션에서 XSS(Cross-Site Scripting)는 단순한 화면 깨짐이나 보기 불편을 넘는 문제입니다.
공격자가 악성 스크립트를 사용자 브라우저에서 실행시키면 쿠키 탈취, 세션 하이재킹, UI 변조, 피싱 화면 삽입 등 사용자의 인증 정보와 민감 데이터를 직접적으로 노출시킬 수 있습니다.
금융 서비스나 개인 정보가 오가는 서비스에서는 한 번의 XSS가 계정 탈취로 이어져 심각한 피해를 초래할 수 있습니다.
OWASP에서도 XSS를 주된 웹 취약점으로 분류하고 있으며, 입력값을 출력으로 내보내는 모든 지점이 잠재적 공격 표면이라는 관점을 강조합니다.

Flask는 Jinja2 템플릿 엔진을 사용해 서버 사이드에서 HTML을 렌더링합니다.
다행히 Flask는 기본 설정에서 `.html`, `.htm`, `.xml`, `.xhtml`, `.svg` 템플릿에 대해 자동 이스케이프를 활성화하여 HTML 문맥에서 사용자 입력이 그대로 실행되지 않도록 해줍니다.
그럼에도 불구하고 개발자가 실수로 이 기능을 무시하거나, 편의상 `|safe` 필터 또는 Markup 클래스를 남발하면 방어막이 깨집니다.
템플릿 안에서 링크의 href에 사용자가 제공한 값을 그대로 넣는 경우(`href=”{{ value }}”`)처럼 브라우저가 실행 가능한 URI(`javascript:`)를 허용하는 맥락은 자동 이스케이프만으로는 완전 방어가 되지 않습니다.

실제 사례로 최근 Jinja2 관련 취약점(CVE-2024-22195)으로 인해 템플릿 처리 과정에서 예상치 못한 XSS가 발생할 수 있음이 보고된 바 있습니다.
이처럼 템플릿 엔진 자체의 취약점이나 개발 실수는 합쳐져 큰 보안 사고로 이어질 수 있으므로, 프레임워크 기본값을 신중하게 다루고 패치 공지에 빠르게 대응하는 것이 중요합니다.

또 다른 중요한 관점은 브라우저 레벨의 보조 방어 수단인 Content Security Policy(CSP)입니다.
CSP는 서버가 응답 헤더로 허용된 스크립트/스타일/리소스 출처를 명시하게 하여, 인라인 스크립트나 외부의 의심스러운 리소스가 실행되는 것을 차단합니다.
특히 nonce(요청마다 생성되는 일회용 토큰)나 해시 기반 스크립트 허용 방식을 사용하면, 인라인 스크립트 실행을 안전하게 제한할 수 있어 XSS 공격 성공 확률을 크게 낮춥니다.
하지만 CSP를 잘못 구성하면 기대한 보호를 못 하므로, 신중한 정책 설계와 테스트가 필요합니다.

요약하자면 Flask에서 XSS가 위험한 이유는 세 가지로 정리할 수 있습니다.
첫째, 사용자 입력이 곧 실행 가능한 코드로 바뀌면 직접적인 계정/데이터 탈취로 이어진다.
둘째, 템플릿 엔진이나 개발자의 실수(`|safe`, untrusted Markup, autoescape 해제 등)가 방어막을 무력화한다.
셋째, 브라우저 단의 보조 수단(CSP)을 올바르게 사용하지 않으면 단순한 이스케이프만으로는 부족할 수 있다.
이 섹션은 Flask 앱을 점검할 때 ‘입력→렌더링’ 경로의 모든 지점을 의심하고 검토해야 한다는 점을 분명히 전달하는 목적입니다.

# 안전하지 않은 템플릿 사용 예시 (XSS 발생 가능)
# templates/comment.html
<div class="comment">
    <p>작성자: {{ author }}</p>
    <p>내용: {{ comment }}</p>   # 자동 이스케이프가 동작해도, 일부 문맥(예: attribute, js URI 등)은 방어가 불완전할 수 있음
</div>

# 위험한 사용: 필터로 안전 처리 표시
<!-- 절대 untrusted input에 사용하지 말 것 -->
<div>{{ comment | safe }}</div>

🧼 Jinja2 템플릿 자동 이스케이프 제대로 이해하기

Flask는 내부적으로 Jinja2 템플릿 엔진을 사용하며, XSS를 막기 위한 가장 기본적인 방어 기법으로 자동 이스케이프(autoescaping) 기능을 제공합니다.
이 기능은 템플릿이 렌더링될 때 HTML 특수문자(<, >, “, ‘)를 자동으로 치환하여 브라우저가 스크립트로 해석하지 못하도록 만들어 줍니다.
즉, 사용자가 입력한 내용이 설령 <script>alert(‘XSS’)</script> 형태라 하더라도 브라우저에는 단순한 문자열로 표시되어 실행되지 않습니다.

Jinja2는 파일 확장자에 따라 자동 이스케이프 적용 여부를 결정합니다.
기본적으로 .html, .htm, .xml, .xhtml, .svg 파일에서는 자동 이스케이프가 활성화되고, .txt나 .jinja 같은 일반 텍스트 파일에서는 비활성화됩니다.
따라서 HTML 템플릿 파일을 반드시 위 확장자로 저장하고, 코드 내에서 render_template() 함수를 통해 렌더링해야 합니다.
직접 Jinja2 환경을 커스터마이징하는 경우라면 아래와 같이 명시적으로 설정할 수도 있습니다.

from flask import Flask, render_template
from jinja2 import Environment

app = Flask(__name__)

# autoescape 설정을 명시적으로 커스터마이징할 수 있음
def select_autoescape(filename):
    if filename is None:
        return True
    return filename.endswith(('.html', '.htm', '.xml', '.xhtml', '.svg'))

app.jinja_env.autoescape = select_autoescape

자동 이스케이프는 강력하지만 모든 경우를 100% 방어하진 않습니다.
예를 들어 JavaScript 코드 블록 안에서 변수 삽입을 잘못하면 여전히 위험이 존재합니다.
또한 HTML 속성, URL, JSON 등 다른 출력 문맥(context)에서는 별도의 이스케이프 처리가 필요합니다.
Flask/Jinja2에서는 이런 문맥을 위해 |tojson 필터, |urlencode 필터 등 다양한 도구를 제공합니다.

🧩 안전한 변수 출력의 기본 규칙

• ✅자동 이스케이프를 비활성화하지 않는다 (autoescape=False 사용 금지)
• ✅safe 필터를 신뢰되지 않은 입력에 절대 사용하지 않는다
• ✅자바스크립트 내부에서 사용하는 값은 |tojson 필터를 적용해 직렬화 후 출력
• ✅URL 파라미터나 링크에 들어갈 값은 |urlencode 필터 사용

Flask 앱의 XSS 방어는 ‘입력 검증’과 ‘출력 이스케이프’가 함께 작동할 때 비로소 완전해집니다.
Jinja2의 자동 이스케이프를 이해하고, 문맥별 적절한 필터를 적용하는 것이 Flask 보안의 기초이자 출발점입니다.

🔒 Content Security Policy 기본과 Strict CSP 전략

자동 이스케이프가 서버 단에서 실행되는 보안 장치라면, Content Security Policy (CSP)는 브라우저 단의 방어막이라고 볼 수 있습니다.
CSP는 웹 페이지가 어떤 스크립트, 스타일, 이미지, 폰트, 프레임을 로드할 수 있는지를 명시하는 보안 정책입니다.
서버가 응답 헤더에 “이런 출처에서만 자원을 불러와라”라고 선언하면 브라우저가 그 규칙을 따르며, 허용되지 않은 소스의 코드 실행을 차단합니다.
즉, 공격자가 스크립트를 주입하더라도 정책상 허용되지 않으면 실행되지 않습니다.

기본적인 CSP 헤더는 다음과 같은 형태를 가집니다.

Content-Security-Policy: default-src 'self';
script-src 'self' https://trusted.cdn.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
object-src 'none';
frame-ancestors 'none';

여기서 'self'는 동일 출처(origin)만 허용한다는 뜻입니다.
즉, 서버 자신이 제공하는 리소스만 사용할 수 있고 외부 CDN이나 서드파티 스크립트는 명시적으로 허용해야 합니다.
'unsafe-inline'이나 'unsafe-eval'은 이름 그대로 위험한 옵션으로, 임시 디버깅 외에는 사용하지 않는 것이 좋습니다.

🔑 Strict CSP 전략과 nonce/hash 방식

최근 보안 커뮤니티에서 권장하는 방향은 Strict CSP입니다.
이는 인라인 스크립트를 전면 차단하고, 오직 nonce나 hash 기반으로 허용된 스크립트만 실행하도록 하는 정책입니다.
nonce는 서버가 요청마다 랜덤하게 생성하는 토큰이며, 다음과 같이 스크립트 태그에 부여됩니다.

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

<script nonce="abc123">
    console.log("이 스크립트만 실행됩니다.");
</script>

이처럼 서버가 매 요청마다 새로운 nonce를 발급해 헤더와 스크립트에 일치하게 포함시키면, 공격자가 임의로 삽입한 스크립트는 실행되지 않습니다.
비슷한 방식으로 스크립트의 SHA256 해시를 미리 계산해 정책에 포함시키는 방법도 있습니다.
예시: script-src 'self' 'sha256-abc123...' 형태입니다.
이 두 방식은 동적 콘텐츠를 많이 사용하는 Flask 앱에도 적합하며, 공격자가 스크립트를 삽입하더라도 정책을 우회하기 어렵습니다.

정리하자면 CSP는 XSS 공격의 마지막 보루입니다.
Flask에서 아무리 서버 단 입력 검증과 이스케이프를 잘해도, 클라이언트 단 정책이 부실하면 공격자가 우회할 가능성이 남습니다.
반대로 CSP를 제대로 설정해두면, 혹시라도 발생할 수 있는 인젝션 취약점의 피해 범위를 극적으로 줄일 수 있습니다.
따라서 Jinja2 이스케이프와 CSP는 함께 작동해야 합니다.

📝 Flask에서 CSP 헤더 적용하는 패턴

Flask 애플리케이션에 Content-Security-Policy를 적용하는 방법은 크게 세 가지 패턴으로 정리할 수 있습니다.
첫째, 확장 라이브러리(예: Flask-Talisman)를 사용하는 방법.
둘째, 응답 레벨에서 직접 헤더를 설정하는 방법.
셋째, nonce를 생성해 템플릿에 주입하는 방식입니다.
각 방법은 장단점이 있으니 서비스 구조와 배포 환경에 맞게 선택하는 것이 중요합니다.

1) Flask-Talisman으로 빠르게 적용하기.
Talisman은 Flask용 경량 확장으로서 여러 보안 헤더(HSTS, X-Frame-Options 등)와 함께 CSP 설정을 쉽게 관리하게 해줍니다.
설치 후 간단히 Talisman(app, content_security_policy=policy) 형태로 사용하면 전역 정책을 일괄 적용할 수 있어 초기 도입 속도가 빠릅니다.
다만 기본 정책이 매우 엄격하므로, 외부 CDN이나 서드파티 스크립트를 사용하는 경우 세부 정책을 명시적으로 조정해야 합니다.

from flask import Flask
from flask_talisman import Talisman

app = Flask(__name__)

csp = {
    "default-src": ["'self'"],
    "script-src": ["'self'", "https://cdn.example.com"]
}

Talisman(app, content_security_policy=csp)

2) 응답(Response)에서 직접 CSP 헤더를 설정하기.
확장 라이브러리를 쓰지 않고, 각 응답에 헤더를 붙이는 방식입니다.
애플리케이션이 복잡하거나, 특정 블루프린트(모듈)별로 정책을 다르게 적용해야 할 때 유연하게 쓸 수 있습니다.
예를 들어 after_request 훅을 사용해 정책을 동적으로 붙이면, 환경별(개발/스테이징/운영)로 다른 정책을 적용하기 수월합니다.

from flask import Flask, request, make_response

app = Flask(__name__)

CSP_HEADER = "default-src 'self'; script-src 'self' https://cdn.example.com"

@app.after_request
def set_csp(response):
    response.headers['Content-Security-Policy'] = CSP_HEADER
    return response

3) nonce 기반 정책으로 동적 스크립트 허용.
애플리케이션이 템플릿 내에서 인라인 스크립트를 사용하거나, 서버가 렌더링하는 스크립트가 매 요청마다 달라지는 경우 nonce 방식을 권장합니다.
서버는 각 요청마다 안전한 랜덤 토큰을 생성하고, 응답 헤더의 script-src에 ‘nonce-‘을 포함시킵니다.
템플릿 안의 <script> 태그에는 동일한 nonce 속성을 넣어 브라우저가 해당 스크립트만 실행하도록 합니다.
이 방식은 인라인 스크립트를 완전 차단하는 엄격한 CSP와 달리 합리적인 유연성을 유지하면서 안전성을 높여줍니다.

import secrets
from flask import Flask, g, render_template

app = Flask(__name__)

def generate_nonce(n=16):
    return secrets.token_urlsafe(n)

@app.before_request
def attach_nonce():
    g.csp_nonce = generate_nonce()

@app.after_request
def add_csp(response):
    nonce = g.get('csp_nonce')
    response.headers['Content-Security-Policy'] = f"default-src 'self'; script-src 'self' 'nonce-{nonce}'"
    return response

# template usage: <script nonce="{{ g.csp_nonce }}">...</script>

단계적 적용 팁: 먼저 Report-Only 모드로 위반 로그를 수집하세요.
운영 중인 페이지에서 CSP를 바로 차단 모드로 두면 정상 동작이 깨질 가능성이 높습니다.
Report-Only 헤더를 통해 브라우저의 위반 리포트를 수집하고, 로그를 분석해 허용해야 할 출처를 확인한 뒤 최종 정책을 적용하면 안전합니다.

마지막 체크리스트(간단).
CSP를 적용했는가.
Report-Only로 먼저 테스트했는가.
필요한 외부 리소스는 명확히 화이트리스트에 올렸는가.
템플릿에서 nonce를 일관되게 주입하고 있는가.
그리고 CSP 위반 리포트를 수집하는 로깅/모니터링 체계를 갖추었는가.
이 항목들을 점검하면 Flask에서 CSP를 효과적으로 운영할 수 있습니다.

🚨 절대 하면 안 되는 보안 안티패턴 체크리스트

Flask 기반 서비스에서 XSS가 실제로 터지는 순간을 보면, “이 정도면 괜찮겠지”라고 대충 넘긴 지점에서 거의 항상 시작됩니다.
아래에 정리한 패턴은 실제로 자주 보이고, 한 번만 방심해도 공격자가 악성 스크립트를 주입해 세션을 훔치거나 페이지를 변조할 수 있는 위험한 습관들입니다.
이 항목들에 해당한다면 지금 바로 코드에서 없애는 게 맞습니다.

🧨 자동 이스케이프를 고의로 꺼버리는 경우

Jinja2의 자동 이스케이프(autoescape)는 Flask에서 XSS를 막아주는 1차 방어막입니다.
그런데 가끔 “디자인이 깨져서요”라는 이유로 전역 autoescape를 꺼버리거나, 특정 블록에 {% autoescape false %}를 선언해버리는 경우가 있습니다.
신뢰할 수 없는 입력이 그 영역으로 들어가는 순간, 공격자는 <script> 태그나 이벤트 핸들러(onclick 등)를 그대로 심을 수 있게 됩니다.
이건 서비스 전체 보안에 구멍을 내는 수준의 결정이라 사실상 금지해야 합니다.

🪤 무분별한 safe 필터와 Markup 사용

Jinja2에서 {{ value | safe }} 또는 Flask의 Markup() 객체는 “이 값은 신뢰해도 되니까 이스케이프하지 말고 그대로 HTML로 박아 넣어”라는 뜻입니다.
문제는 우리가 신뢰한다고 해서 실제로 안전하다는 보장이 없다는 점입니다.
운영 현장에서 가장 흔한 사고 패턴은, 관리자가 직접 입력한 HTML이라고 믿고 safe 처리했는데 그 값이 나중에 일반 사용자 입력과 섞여 재활용되는 케이스입니다.
결국 공격자가 그 틈을 타 악성 스크립트를 주입하게 됩니다.

일반 사용자가 업로드하는 프로필 소개, 게시물 본문, 상품 설명, Q&A 답변 등은 safe로 출력하면 안 됩니다.
이런 콘텐츠에 HTML 허용이 꼭 필요하다면, 서버에서 화이트리스트 방식의 HTML sanitizer(예: 허용된 태그만 남기고 다 지우는 방식)를 먼저 통과시키고 나서 렌더링해야 합니다.

🪪 쿠키/세션 탈취를 과소평가하는 경우

XSS는 단순 장난이 아니라, 로그인된 사용자의 세션을 공격자 서버로 전송해 계정을 그대로 가져가는 공격으로 이어질 수 있습니다.
따라서 Flask 세션 쿠키에는 HttpOnly와 Secure 옵션을 설정해 자바스크립트에서 접근하지 못하게 하고 HTTPS 환경에서만 전송되게 해야 합니다.
즉, 애초에 탈취 가능한 정보 자체를 최소화하는 전략이 필요합니다.

🧷 CSP를 아예 적용하지 않거나, ‘unsafe-inline’으로 무력화하는 경우

Content Security Policy는 한마디로 “브라우저에서 어떤 스크립트가 실제로 실행될 수 있는지”를 허가제로 바꾸는 역할을 합니다.
그런데 CSP를 아예 설정하지 않으면 공격자가 주입한 스크립트가 그대로 실행될 수 있습니다.
반대로 CSP를 걸어두고도 'unsafe-inline'을 script-src에 넣어버리면, 인라인 스크립트는 전부 허용되는 셈이라 사실상 방어 효과가 크게 줄어듭니다.
즉 선언만 있고 실질적 제약은 없는 CSP는 “보안 점수 채우기용” 그 이상이 되지 못합니다.

정리하자면, 아래 네 가지는 즉시 교체 또는 금지 대상입니다.
1) autoescape 끄기.
2) 아무 입력에나 safe/Markup 붙이기.
3) HttpOnly/ Secure 없이 세션 쿠키 노출시키기.
4) CSP 없이 운영하거나, ‘unsafe-inline’에 의존하기.
이런 습관을 없애는 것만으로도 Flask 앱의 XSS 공격 표면을 눈에 띄게 줄일 수 있습니다.

❓ 자주 묻는 질문 (FAQ)

🧩 Flask 웹 보안의 핵심 정리

Flask는 간결하고 강력한 웹 프레임워크이지만, 보안을 놓치면 공격자에게는 아주 쉬운 표적이 될 수 있습니다.
이번 글에서는 Flask에서 가장 중요한 취약점 중 하나인 XSS를 중심으로 살펴봤습니다.
이 문제의 핵심은 “사용자 입력이 그대로 실행되면 안 된다”는 단순한 원칙이지만, 그 원칙을 시스템적으로 지켜주는 장치들이 바로 자동 이스케이프(autoescape)와 Content Security Policy(CSP)입니다.

자동 이스케이프는 서버 단에서 HTML 문맥을 보호하고, CSP는 브라우저가 승인된 스크립트만 실행하도록 통제합니다.
이 두 보안 계층이 함께 작동할 때 Flask 애플리케이션은 훨씬 안전해집니다.
또한 개발자가 실수로 |safe를 잘못 쓰거나 autoescape를 끈다면 모든 보안 구조가 무너질 수 있으므로, “기본 설정을 믿고 유지하는 것”이 오히려 최고의 방어가 됩니다.

추가로, CSP는 Report-Only 모드로 점진적으로 적용하고, 세션 쿠키는 HttpOnly·Secure·SameSite 옵션으로 보호하며, 모든 사용자 입력은 HTML 컨텍스트에 맞게 이스케이프하거나 검증 필터를 통과시키는 습관을 들여야 합니다.
보안은 거창한 설정이 아니라, 이런 세부 습관들의 꾸준한 실천에서 나옵니다.

정리하자면 Flask 보안의 핵심은 세 가지로 요약됩니다.
자동 이스케이프를 항상 유지한다.
CSP를 적용해 브라우저 실행 정책을 강제한다.
개발자의 “이 정도는 괜찮겠지”라는 예외를 최소화한다.
이 세 가지를 일관되게 적용하면, Flask 웹 애플리케이션은 현실적으로 XSS 공격에 매우 강한 방어력을 갖게 됩니다.

🏷️ 관련 태그 : Flask보안, 파이썬웹, XSS방지, Jinja2, 자동이스케이프, ContentSecurityPolicy, 웹취약점, CSP설정, 세션보호, 웹개발기초