Introdução

O Desafio de Segurança do Conteúdo Renderizado no Servidor

Ao construir aplicações web modernas com Svelte 5, a renderização no lado do servidor (SSR) oferece benefícios significativos: carregamentos iniciais de página mais rápidos, melhor SEO e experiência de usuário aprimorada. No entanto, o SSR introduz uma consideração de segurança que muitos desenvolvedores ignoram até se depararem com erros misteriosos do navegador: violações de Content Security Policy (CSP).

A função hydratable no Svelte 5 é uma ferramenta poderosa que evita buscas de dados redundantes durante a hidratação. Quando você usa hydratable, o Svelte serializa os dados obtidos no servidor e os incorpora em um bloco <script> inline dentro do <head> do documento. Essa abordagem é elegante e eficiente—mas colide diretamente com Políticas de Segurança de Conteúdo rígidas que bloqueiam scripts inline.

A partir do Svelte 5.46.0, a função render agora inclui uma opção csp que permite especificar um nonce ou solicitar hashes para esses scripts inline. Essa adição aparentemente pequena desbloqueia a capacidade de usar hydratable em ambientes com requisitos de segurança rigorosos sem recorrer à perigosa diretiva unsafe-inline.

Vamos explorar esse recurso de forma abrangente—desde entender por que ele importa até implementá-lo em cenários do mundo real.

Entendendo a Content Security Policy

Antes de mergulhar no suporte a CSP do Svelte, vamos estabelecer uma compreensão sólida do que é CSP e por que ela existe.

O que é CSP?

Content Security Policy é um padrão de segurança que ajuda a prevenir ataques de cross-site scripting (XSS), clickjacking e outras injeções de código. Ele funciona permitindo que você especifique exatamente quais recursos o navegador deve confiar e executar.

Uma CSP é entregue por meio de um cabeçalho de resposta HTTP:

Content-Security-Policy: script-src 'self'; style-src 'self' https://fonts.googleapis.com

Este cabeçalho diz ao navegador: "Execute apenas scripts do meu próprio domínio e carregue apenas estilos do meu domínio ou do Google Fonts."

O Problema dos Scripts Inline

Por padrão, quando a CSP está habilitada com uma diretiva script-src, o navegador bloqueia todos os scripts inline. Isso inclui:

<!-- This will be blocked -->
<script>
	const user = { name: 'Alice', role: 'admin' }
	window.__SVELTE_DATA__ = user
</script>

A justificativa é sólida: scripts inline são um vetor primário para ataques XSS. Se um invasor consegue injetar HTML na sua página, ele pode injetar JavaScript malicioso que é executado imediatamente.

No entanto, aplicações legítimas—como o Svelte com hydratable—precisam incorporar scripts inline por razões válidas. A solução? Nonces e hashes.

Nonces vs. Hashes: Duas Abordagens

Nonces (Número Usado Uma Vez) são valores gerados aleatoriamente que você:

Gera no servidor para cada resposta HTTP
Inclui no seu cabeçalho CSP: script-src 'nonce-abc123'
Adiciona às suas tags de script: <script nonce="abc123">

O navegador então permite que apenas scripts com o nonce correspondente sejam executados.

Hashes são impressões digitais criptográficas do conteúdo do script:

Você calcula o hash SHA-256 (ou SHA-384/SHA-512) do conteúdo do seu script
Inclui o hash no seu cabeçalho CSP: script-src 'sha256-abc123...'
O navegador calcula o hash de qualquer script inline e verifica se ele corresponde

Aqui está uma comparação para ajudá-lo a escolher:

Aspecto	Nonces	Hashes
Geração	Aleatório, por requisição	Calculado a partir do conteúdo
Cache	Quebra o cache de respostas	Permite respostas em cache
Conteúdo dinâmico	Ideal para SSR	Requer conteúdo estático
Complexidade	Requer coordenação com servidor	Pode ser pré-configurado
Streaming SSR	✅ Compatível	❌ Pode interferir

Como observa a documentação do Svelte: prefira nonces em vez de hashes quando possível, porque hashes irão interferir com o streaming SSR no futuro.

A Função Hydratable: Uma Revisão Rápida

Antes de explorar a integração com CSP, vamos entender o que hydratable faz e por que ele gera scripts inline.

O Problema da Hidratação

Considere este componente Svelte:

<script>
	import { getUser } from 'my-database-library'

	// This runs on the server during SSR
	const user = await getUser()
</script>

<h1>Welcome, {user.name}!</h1>

Durante o SSR, o Svelte busca o usuário e renderiza o HTML. Mas durante a hidratação (quando o JavaScript do lado do cliente assume o controle), o Svelte encontra aquela mesma chamada await getUser(). Sem nenhum mecanismo para passar os dados do servidor para o cliente, o Svelte busca o usuário novamente—desperdiçando tempo e potencialmente causando piscadas na interface se os dados diferirem.

Como o Hydratable Resolve Isso

A função hydratable preenche essa lacuna de forma elegante:

<script>
	import { hydratable } from 'svelte'
	import { getUser } from 'my-database-library'

	const user = await hydratable('user', () => getUser())
</script>

<h1>Welcome, {user.name}!</h1>

Veja o que acontece em cada etapa:

Renderização no servidor: hydratable chama getUser(), serializa o resultado e o incorpora em um bloco <script> no <head>.
Hidratação: hydratable encontra os dados serializados pela chave 'user' e os retorna imediatamente—sem necessidade de requisição de rede.
Pós-hidratação: Se hydratable for chamado novamente (por exemplo, em um contexto reativo), ele simplesmente chama getUser() normalmente.

Os dados serializados usam devalue, que pode lidar com tipos complexos como Map, Set, Date, URL, BigInt e até Promise.

O Script Gerado

Quando você usa hydratable, o Svelte gera algo assim no <head> do seu documento:

<script>
	(function() {
	  const __SVELTE_HYDRATABLE_DATA__ = /* serialized data */;
	  // Registration logic
	})();
</script>

Esse script inline é o que a CSP bloqueia—e o que a nova opção csp permite que você proteja.

Usando a Opção CSP em render()

A função render de svelte/server agora aceita uma opção csp com dois modos: nonce e hash.

API Básica

import { render } from 'svelte/server'
import App from './App.svelte'

// Option 1: Using a nonce
const { head, body } = await render(App, {
	csp: { nonce: 'your-random-nonce' }
})

// Option 2: Using hashes
const { head, body, hashes } = await render(App, {
	csp: { hash: true }
})

Observe que ao usar hashes, a função render retorna uma propriedade adicional hashes contendo os valores de hash calculados.

O Tipo RenderOutput

Para usuários de TypeScript, aqui está a estrutura:

interface RenderOutput {
	head: string
	body: string
	hashes?: {
		script: string[] // Array of hash strings like ['sha256-abc123...']
	}
}

Implementação Prática: CSP Baseada em Nonce

Vamos construir um exemplo completo usando nonces em um ambiente Node.js/Express.

Passo 1: Gerar um Nonce

Cada resposta HTTP precisa de um nonce único e criptograficamente seguro:

// server.js
import crypto from 'node:crypto'
import express from 'express'
import { render } from 'svelte/server'
import App from './App.svelte'

const app = express()

app.get('*', async (req, res) => {
	// Generate a cryptographically secure random nonce
	const nonce = crypto.randomBytes(16).toString('base64')

	// Render the Svelte app with the nonce
	const { head, body } = await render(App, {
		props: { url: req.url },
		csp: { nonce }
	})

	// Set the CSP header with the nonce
	res.setHeader(
		'Content-Security-Policy',
		`script-src 'self' 'nonce-${nonce}'; style-src 'self' 'unsafe-inline'`
	)

	// Send the HTML response
	res.send(`
    <!DOCTYPE html>
    <html>
      <head>
        <meta charset="utf-8">
        ${head}
      </head>
      <body>
        ${body}
        <script nonce="${nonce}" src="/app.js"></script>
      </body>
    </html>
  `)
})

app.listen(3000)

Passo 2: Entendendo o que o Svelte Faz

Quando você passa csp: { nonce } para render, o Svelte adiciona o atributo nonce ao script gerado:

<!-- Without CSP option -->
<script>
	/* hydratable data */
</script>

<!-- With csp: { nonce: 'abc123' } -->
<script nonce="abc123">
	/* hydratable data */
</script>

Passo 3: Não Esqueça os Seus Próprios Scripts

Quaisquer outros scripts inline ou tags de script que você adicionar também devem incluir o nonce:

<!-- Main application bundle -->
<script nonce="${nonce}" src="/build/app.js"></script>

<!-- Analytics (if inline) -->
<script nonce="${nonce}">
	// Tracking code
</script>

Considerações de Segurança para Nonces

Várias práticas críticas de segurança se aplicam aos nonces:

Nunca reutilize nonces: Gere um novo valor aleatório para cada resposta HTTP.
Use aleatoriedade criptográfica: Math.random() não é seguro. Use crypto.randomBytes() ou crypto.randomUUID().
Não exponha nonces em URLs: Nonces devem trafegar apenas em cabeçalhos HTTP e atributos HTML, nunca em query strings ou dados de formulário.
Combine com strict-dynamic: A CSP moderna suporta 'strict-dynamic', que permite que scripts carregados por scripts confiáveis sejam executados:

Content-Security-Policy: script-src 'nonce-abc123' 'strict-dynamic'

Implementação Prática: CSP Baseada em Hash

Para geração de sites estáticos ou quando você não pode gerar nonces por requisição, os hashes fornecem uma alternativa.

Passo 1: Renderizar com a Opção Hash

// build.js
import { render } from 'svelte/server'
import fs from 'node:fs'
import App from './App.svelte'

async function buildPage() {
	const { head, body, hashes } = await render(App, {
		csp: { hash: true }
	})

	// hashes.script contains something like ['sha256-xyz789...']
	console.log('Script hashes:', hashes.script)

	// Generate the CSP header value
	const scriptSrc = hashes.script.map((h) => `'${h}'`).join(' ')

	// For static sites, embed CSP in a meta tag
	const html = `
    <!DOCTYPE html>
    <html>
      <head>
        <meta charset="utf-8">
        <meta http-equiv="Content-Security-Policy" 
              content="script-src 'self' ${scriptSrc}">
        ${head}
      </head>
      <body>
        ${body}
        <script src="/app.js"></script>
      </body>
    </html>
  `

	fs.writeFileSync('dist/index.html', html)

	// Store hashes for server configuration
	fs.writeFileSync('dist/csp-hashes.json', JSON.stringify(hashes))
}

buildPage()

Passo 2: Configurar Seu Servidor

Para implantação em produção, configure seu servidor web para enviar o cabeçalho CSP. Aqui está um exemplo para Nginx:

# nginx.conf
server {
    location / {
        add_header Content-Security-Policy "script-src 'self' 'sha256-xyz789...'";
        try_files $uri $uri/ /index.html;
    }
}

Ou para Apache:

# .htaccess
Header set Content-Security-Policy "script-src 'self' 'sha256-xyz789...'"

Ressalva Importante: Mudanças no Conteúdo Invalidam os Hashes

Se seus dados hydratable mudarem entre builds, o hash também muda. Isso significa que:

Você deve fazer rebuild e atualizar os cabeçalhos CSP sempre que o conteúdo mudar
CSP baseado em hash é primariamente adequado para conteúdo verdadeiramente estático
Para SSR dinâmico, prefira nonces

Integração com SvelteKit

SvelteKit possui seu próprio sistema de configuração CSP que funciona em conjunto (mas separadamente) com o suporte a CSP do hydratable do Svelte. Entender como eles interagem é fundamental.

CSP Integrado do SvelteKit

SvelteKit permite configurar CSP no svelte.config.js:

// svelte.config.js
export default {
	kit: {
		csp: {
			mode: 'auto', // 'hash', 'nonce', or 'auto'
			directives: {
				'script-src': ['self'],
				'style-src': ['self', 'unsafe-inline']
			}
		}
	}
}

Esta configuração lida com os scripts e estilos inline do próprio SvelteKit. A configuração mode: 'auto' usa hashes para páginas pré-renderizadas e nonces para páginas renderizadas dinamicamente.

Usando Hydratable com SvelteKit

Para a maioria das aplicações SvelteKit, você não chamará render() diretamente — o SvelteKit cuida disso. A função hydratable é tipicamente utilizada nos bastidores por bibliotecas de busca de dados.

No entanto, se você estiver construindo uma configuração SSR personalizada ou integrando com hydratable diretamente, pode usar o hook handle do SvelteKit para coordenar o CSP:

// src/hooks.server.js
import crypto from 'node:crypto'

export async function handle({ event, resolve }) {
	// Generate a nonce for this request
	const nonce = crypto.randomUUID()

	// Store it for use in load functions if needed
	event.locals.nonce = nonce

	const response = await resolve(event, {
		transformPageChunk: ({ html }) => {
			// Inject nonce into any custom scripts
			return html.replace(/<script>/g, `<script nonce="${nonce}">`)
		}
	})

	// Add CSP header
	response.headers.set(
		'Content-Security-Policy',
		`script-src 'self' 'nonce-${nonce}' 'strict-dynamic'; style-src 'self' 'unsafe-inline'`
	)

	return response
}

O Placeholder `%sveltekit.nonce%` do SvelteKit

O SvelteKit fornece um placeholder especial para nonces no src/app.html:

<!doctype html>
<html>
	<head>
		<meta charset="utf-8" />
		%sveltekit.head%
	</head>
	<body>
		%sveltekit.body%
		<script nonce="%sveltekit.nonce%">
			// Your inline script here
		</script>
	</body>
</html>

O SvelteKit substitui automaticamente %sveltekit.nonce% pelo nonce gerado quando o modo CSP inclui nonces.

Exemplo do Mundo Real: Busca de Dados Segura

Vamos construir um exemplo completo que demonstra hydratable com CSP em um cenário realista.

O Cenário

Você está construindo um dashboard que exibe dados específicos do usuário. Os dados devem ser buscados uma vez no servidor e passados ao cliente sem necessidade de nova busca.

Configuração do Servidor (Node.js)

// server.js
import express from 'express'
import crypto from 'node:crypto'
import { render } from 'svelte/server'
import Dashboard from './Dashboard.svelte'

const app = express()

// Middleware to generate nonce
app.use((req, res, next) => {
	res.locals.nonce = crypto.randomBytes(16).toString('base64url')
	next()
})

// API endpoint for client-side fetches
app.get('/api/user/:id', async (req, res) => {
	const user = await fetchUserFromDatabase(req.params.id)
	res.json(user)
})

// SSR route
app.get('/dashboard', async (req, res) => {
	const { nonce } = res.locals

	try {
		const { head, body } = await render(Dashboard, {
			props: {
				userId: req.session.userId
			},
			csp: { nonce }
		})

		// Build CSP header
		const cspDirectives = [
			`default-src 'self'`,
			`script-src 'self' 'nonce-${nonce}' 'strict-dynamic'`,
			`style-src 'self' 'unsafe-inline'`,
			`img-src 'self' data: https:`,
			`connect-src 'self'`,
			`font-src 'self'`,
			`object-src 'none'`,
			`base-uri 'self'`,
			`form-action 'self'`,
			`frame-ancestors 'none'`
		].join('; ')

		res.setHeader('Content-Security-Policy', cspDirectives)

		res.send(`
      <!DOCTYPE html>
      <html lang="en">
        <head>
          <meta charset="UTF-8">
          <meta name="viewport" content="width=device-width, initial-scale=1.0">
          <title>Dashboard</title>
          ${head}
        </head>
        <body>
          <div id="app">${body}</div>
          <script nonce="${nonce}" type="module" src="/build/main.js"></script>
        </body>
      </html>
    `)
	} catch (error) {
		console.error('Render error:', error)
		res.status(500).send('Internal Server Error')
	}
})

async function fetchUserFromDatabase(id) {
	// Simulated database fetch
	return {
		id,
		name: 'Alice Johnson',
		email: 'alice@example.com',
		role: 'admin',
		lastLogin: new Date()
	}
}

app.listen(3000, () => {
	console.log('Server running on http://localhost:3000')
})

Componente Svelte

<!-- Dashboard.svelte -->
<script>
	import { hydratable } from 'svelte'
	import UserCard from './UserCard.svelte'
	import ActivityFeed from './ActivityFeed.svelte'

	let { userId } = $props()

	// Fetch user data with hydratable
	// Server: fetches and serializes
	// Client: uses serialized data during hydration
	const user = await hydratable(`user-${userId}`, async () => {
		const response = await fetch(`/api/user/${userId}`)
		if (!response.ok) error('Failed to fetch user')
		return response.json()
	})

	// Multiple hydratable calls can coexist
	const activities = await hydratable(`activities-${userId}`, async () => {
		const response = await fetch(`/api/activities/${userId}`)
		return response.json()
	})
</script>

<main class="dashboard">
	<header>
		<h1>Welcome back, {user.name}!</h1>
		<p>Last login: {user.lastLogin.toLocaleString()}</p>
	</header>

	<div class="dashboard-grid">
		<section class="user-section">
			<UserCard {user} />
		</section>

		<section class="activity-section">
			<h2>Recent Activity</h2>
			<ActivityFeed items={activities} />
		</section>
	</div>
</main>

<style>
	.dashboard {
		max-width: 1200px;
		margin: 0 auto;
		padding: 2rem;
	}

	.dashboard-grid {
		display: grid;
		grid-template-columns: 300px 1fr;
		gap: 2rem;
		margin-top: 2rem;
	}
</style>

Pontos-Chave Neste Exemplo

Chaves únicas: Cada chamada hydratable usa uma chave única que inclui o ID do usuário, garantindo isolamento de dados entre usuários.
Tratamento de erros: A busca inclui tratamento de erros que será propagado adequadamente durante o SSR e a hidratação.
Tipos complexos: O user.lastLogin é um objeto Date — hydratable lida com isso automaticamente via devalue.
CSP rigoroso: O exemplo usa um CSP abrangente com strict-dynamic, que é a abordagem moderna recomendada.

Tratando Erros e Casos de Borda

O Que Acontece Sem Configuração de CSP?

Se você usar hydratable sem a opção CSP e seu servidor enviar cabeçalhos CSP, você verá erros no console do navegador como:

Refused to execute inline script because it violates the following
Content Security Policy directive: "script-src 'self'". Either the
'unsafe-inline' keyword, a hash ('sha256-xyz...'), or a nonce
('nonce-...') is required to enable inline execution.

A página será renderizada (porque o SSR foi concluído), mas a hidratação falhará silenciosamente e sua aplicação não será interativa.

Desenvolvimento vs. Produção

Durante o desenvolvimento, você pode querer relaxar o CSP para evitar a geração constante de nonces:

const isDev = process.env.NODE_ENV === 'development'

const cspOptions = isDev
	? undefined // No CSP during development
	: { nonce: crypto.randomUUID() }

const { head, body } = await render(App, {
	csp: cspOptions
})

No entanto, recomendo testar com CSP habilitado periodicamente para detectar problemas cedo.

Modo Report-Only para Testes

Antes de aplicar o CSP, use Content-Security-Policy-Report-Only para identificar violações sem interromper a funcionalidade:

res.setHeader(
	'Content-Security-Policy-Report-Only',
	`script-src 'self' 'nonce-${nonce}'; report-uri /csp-violations`
)

Configure um endpoint para coletar e registrar as violações:

app.post('/csp-violations', express.json({ type: 'application/csp-report' }), (req, res) => {
	console.log('CSP Violation:', req.body)
	res.status(204).end()
})

Padrões Avançados

Combinando com Scripts de Terceiros

Quando você precisa carregar scripts de terceiros (analytics, processadores de pagamento, etc.), estenda seu CSP adequadamente:

const cspDirectives = [
	`script-src 'self' 'nonce-${nonce}' https://js.stripe.com`,
	`frame-src https://js.stripe.com`,
	`connect-src 'self' https://api.stripe.com`
].join('; ')

Ou use strict-dynamic com um padrão de carregador:

<script nonce="${nonce}">
	// This trusted script can load other scripts
	const stripeScript = document.createElement('script')
	stripeScript.src = 'https://js.stripe.com/v3/'
	document.head.appendChild(stripeScript)
</script>

Com 'strict-dynamic', scripts carregados por scripts protegidos por nonce são automaticamente confiáveis.

Server-Sent Events e WebSockets

Se sua aplicação usa SSE ou WebSockets, certifique-se de que sua diretiva connect-src os permite:

const cspDirectives = [
	`script-src 'self' 'nonce-${nonce}'`,
	`connect-src 'self' wss://your-domain.com`
].join('; ')

Web Workers

Web Workers carregados do seu domínio funcionam com script-src 'self'. Para workers inline (URLs blob), você precisará adicionar blob::

;`script-src 'self' 'nonce-${nonce}' blob:`

Considerações de Performance

Overhead de Geração de Nonce

Gerar valores aleatórios criptograficamente seguros tem um custo, embora seja mínimo em hardware moderno:

// Fast: ~0.01ms per call
crypto.randomBytes(16).toString('base64url')

// Also fast: ~0.01ms per call
crypto.randomUUID()

Para servidores com taxa de transferência extremamente alta, você poderia pré-gerar um pool de nonces, mas isso raramente é necessário.

Computação de Hash

A computação de hash é ligeiramente mais cara:

import crypto from 'node:crypto'

function computeHash(content) {
	return 'sha256-' + crypto.createHash('sha256').update(content, 'utf8').digest('base64')
}

O Svelte computa hashes automaticamente quando você usa csp: { hash: true }, portanto isso acontece durante a renderização.

Implicações de Cache

Nonces: Cada resposta é única, quebrando o cache de CDN. Use nonces para conteúdo personalizado ou dinâmico.
Hashes: As respostas podem ser armazenadas em cache se o conteúdo for verdadeiramente estático. Ideal para geração de sites estáticos.

Para aplicações que servem tanto páginas estáticas quanto dinâmicas, considere:

const cspOptions = isStaticPage ? { hash: true } : { nonce: crypto.randomUUID() }

Compatibilidade com Navegadores

O CSP Nível 2 (que inclui nonces) tem excelente suporte nos navegadores:

Navegador	Versão
Chrome	40+
Firefox	31+
Safari	10+
Edge	15+

Para navegadores mais antigos, você pode adicionar diretivas de fallback:

Content-Security-Policy: script-src 'nonce-abc123' 'unsafe-inline' 'strict-dynamic' https:

Navegadores modernos ignoram 'unsafe-inline' quando um nonce está presente, enquanto navegadores mais antigos recorrem a ele. O fallback https: fornece proteção básica.

Testando Seu CSP

Ferramentas de Desenvolvedor do Navegador

O DevTools do Chrome exibe claramente as violações de CSP no Console. A aba Network mostra os recursos bloqueados.

Validadores Online

CSP Evaluator - Ferramenta do Google para analisar seu CSP
Report URI - Relatórios e análise de CSP hospedados
Observatory by Mozilla - Verificação de segurança abrangente

Testes Automatizados

Inclua a validação de CSP em seu pipeline de CI/CD:

// csp.test.js
import { test, expect } from 'vitest'
import { render } from 'svelte/server'
import App from './App.svelte'

test('render includes nonce in script tags', async () => {
	const nonce = 'test-nonce-123'
	const { head } = await render(App, { csp: { nonce } })

	expect(head).toContain(`nonce="${nonce}"`)
})

test('render returns hashes when requested', async () => {
	const { hashes } = await render(App, { csp: { hash: true } })

	expect(hashes).toBeDefined()
	expect(hashes.script).toBeInstanceOf(Array)
	expect(hashes.script.length).toBeGreaterThan(0)
	expect(hashes.script[0]).toMatch(/^sha256-/)
})

Resumo: Checklist de Boas Práticas

Aqui está uma referência rápida para implementar CSP com o hydratable do Svelte:

Escolha o Modo Correto:

✅ Use nonces para conteúdo dinâmico renderizado no servidor
✅ Use hashes apenas para geração de sites estáticos
❌ Evite unsafe-inline — isso anula o propósito do CSP

Implemente com Segurança:

✅ Gere nonces com crypto.randomBytes() ou crypto.randomUUID()
✅ Use strict-dynamic para simplificar o carregamento de scripts de terceiros
✅ Inclua object-src 'none' e base-uri 'self' para defesa em profundidade

Teste Completamente:

✅ Use Content-Security-Policy-Report-Only primeiro
✅ Configure o relatório de violações
✅ Teste em diferentes navegadores e cenários

Faça o Deploy com Cuidado:

✅ Monitore violações após o deploy
✅ Tenha um plano de rollback caso o CSP quebre funcionalidades
✅ Documente as decisões de CSP para sua equipe

Leitura Adicional

MDN: Content Security Policy - Referência abrangente de CSP
Guia CSP do Google - Guia de implementação de CSP estrito
OWASP CSP Cheat Sheet - Boas práticas com foco em segurança
Documentação do Svelte Hydratable - Documentação oficial do Svelte
GitHub PR #17338 - A implementação original

Conclusão

O suporte a CSP adicionado à função hydratable do Svelte na v5.46.0 fecha uma lacuna importante para aplicações que priorizam a segurança. Ao fornecer opções simples tanto para nonces quanto para hashes, o Svelte permite que os desenvolvedores aproveitem os benefícios da hidratação otimizada enquanto mantêm Políticas de Segurança de Conteúdo rígidas.

Lembre-se: segurança não é uma funcionalidade que você adiciona no final — é uma mentalidade que você aplica ao longo de todo o desenvolvimento. Com essa nova capacidade, não há desculpa para não implementar um CSP adequado em suas aplicações Svelte desde o primeiro dia.