Os programadores geralmente confiam no conteúdo de campos ocultos, esperando que os usuários não sejam capazes de visualizar esses campos ou de manipular seu conteúdo. Os invasores violarão essas suposições. Eles vão examinar os valores gravados em campos ocultos e alterá-los ou substituir o conteúdo por dados de ataque.

Exemplo:

  Hidden hidden = new Hidden(element);

Se campos ocultos contiverem informações confidenciais, estas serão armazenadas em cache da mesma forma que o restante da página. Isso pode fazer com que informações confidenciais sejam escondidas no cache do navegador sem o conhecimento do usuário.

Uma das características do HTML5 é a capacidade de armazenar dados em um banco de dados SQL do lado do cliente. A principal informação necessária para iniciar a gravação e a leitura do banco de dados é o nome dele. Portanto, é crucial que o nome do banco de dados seja uma cadeia única diferente para cada usuário. Se o nome do banco de dados for fácil de adivinhar, terceiros não autorizados, como outros usuários, podem ser capazes de roubar dados confidenciais ou corromper as entradas do banco de dados.
Exemplo: Este código usa um nome de banco de dados fácil de adivinhar:

...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...

Este código será executado com sucesso, mas qualquer pessoa que possa adivinhar o nome do banco de dados como 'mydb' pode acessá-lo.

A Content Security Policy (CSP) é um cabeçalho de segurança declarativa que permite que os desenvolvedores estipulem de quais domínios o site tem permissão para fazer o upload de conteúdo ou para iniciar conexões durante a renderização no navegador da web. Isso fornece uma camada adicional de segurança contra vulnerabilidades críticas, como criação de script entre sites, clickjacking, acesso entre origens e similares, sobre a validação de entrada e a criação de uma lista de permissões no código. Um cabeçalho configurado incorretamente, no entanto, deixa de fornecer essa camada adicional de segurança. A política é definida com a ajuda de quinze diretivas, incluindo oito que controlam o acesso aos recursos, a saber: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src.

Cada uma delas tem uma lista de fontes uma vez que permite-se a um valor que especifica domínios do site acessar um recurso abrangido por esta diretiva. Os desenvolvedores podem usar um curinga * para indicar a totalidade ou parte da fonte. Nenhuma das diretrizes é obrigatória. Os navegadores autorizarão todas as fontes de uma diretiva não listada ou derivarão o valor delas a partir da diretiva default-src opcional. Ademais, a especificação para esse cabeçalho tem evoluído ao longo do tempo. Ela foi implementada como X-Content-Security-Policy no Firefox até a versão 23 e no IE até a versão 10, e foi implementada como X-Webkit-CSP no Chrome até a versão 25. Os dois nomes foram substituídos pelo atual nome padrão Content Security Policy. Dada a quantidade de diretivas, dois nomes alternativos obsoletos, e a forma como várias ocorrências do mesmo cabeçalho e diretivas repetidas em um único cabeçalho são tratados, há uma alta probabilidade de que um desenvolvedor possa configurar mal esse cabeçalho.

Considere as seguintes situações de configuração incorreta:

- As diretivas com unsafe-inline ou unsafe-eval torna o objetivo da CSP inútil.
- A diretiva script-src é definida mas nenhum script nonce é configurado.
- A diretiva frame-src é definida mas nenhum script sandbox é configurado.
- Várias instâncias desse cabeçalho são permitidas na mesma resposta. A equipe de desenvolvimento e a equipe de segurança podem definir um cabeçalho, mas pode-se usar um dos nomes obsoletos. Enquanto os cabeçalhos obsoletos são liquidados se um cabeçalho com o nome mais recente (ou seja, a Content Security Policy) não estiverem presentes, eles são ignorados se uma política com o nome de conteúdo de segurança de cabeçalho estiver presente. As versões mais antigas só compreendem nomes obsoletos, portanto, a fim de conquistar o apoio desejado, é essencial que a resposta inclua uma política idêntica com todos os três nomes.
- Se uma diretiva for repetida dentro da mesma instância do cabeçalho, todas as ocorrências subsequentes serão ignoradas.

Exemplo 1: Esta configuração django-csp utiliza unsafe-inline e unsafe-eval diretivas inseguras para permitir scripts embutidos e avaliação de código:

...
MIDDLEWARE_CLASSES = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

A CSP (Política de Segurança de Conteúdo) é um cabeçalho de segurança declarativa que permite aos desenvolvedores ditar de quais domínios o local tem permissão para carregar conteúdo ou iniciar conexões durante a renderização no navegador da Web. Ela fornece uma camada adicional de segurança contra vulnerabilidades críticas, como cross-site scripting, clickjacking, acesso entre origens e similares, sobre a validação de entrada e a verificação de lista de permissões no código.

O Spring Security e outras estruturas não adicionam cabeçalhos da Política de Segurança de Conteúdo por padrão. O autor do aplicativo Web deve declarar as políticas de segurança a serem impostas ou monitoradas para que os recursos protegidos se beneficiem dessa camada adicional de segurança.

Se você permitir que seu site seja adicionado a um quadro, isso poderá acarretar um problema de segurança. Por exemplo, isso pode levar a vulnerabilidades de clickjacking ou permitir comunicações indesejadas entre quadros.

Por padrão, estruturas como o Spring Security incluem o cabeçalho X-Frame-Options para indicar ao navegador se o aplicativo deve ser enquadrado. Se você desabilitar ou não definir esse cabeçalho, isso poderá levar a vulnerabilidades entre quadros.

Exemplo 1: O seguinte código configura um aplicativo protegido do Spring Security para desabilitar o cabeçalho X-Frame-Options:

	<http auto-config="true">
        ...
        <headers>
            ...
            <frame-options disabled="true"/>
        </headers>
	</http>

A CSP (Política de Segurança de Conteúdo) é um cabeçalho de segurança declarativo que permite que os desenvolvedores especifiquem o comportamento permitido relacionado à segurança no navegador, incluindo uma lista de permissões locais dos quais o conteúdo pode ser recuperado. Ela fornece uma camada adicional de segurança contra vulnerabilidades críticas, como cross-site scripting, clickjacking, acesso entre origens e similares, sobre a validação de entrada e a verificação de lista de permissões no código. Um cabeçalho configurado incorretamente, no entanto, deixa de fornecer esta camada adicional de segurança. A política é definida com a ajuda de quinze diretivas, incluindo oito que controlam o acesso aos recursos: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. Essas oito diretivas usam uma lista de fontes como um valor que especifica domínios que o site pode acessar para um recurso abrangido por essa diretiva. Os desenvolvedores podem usar um curinga * para indicar a totalidade da fonte ou parte dela. Palavras-chave adicionais da lista de fontes, como 'unsafe-inline' e 'unsafe-eval', fornecem um controle mais granular sobre a execução do script, mas são potencialmente prejudiciais. Nenhuma das diretrizes é obrigatória. Os navegadores permitem todas as fontes para uma diretiva não listada ou derivam seu valor da diretiva opcional default-src. Ademais, a especificação para esse cabeçalho tem evoluído ao longo do tempo. Ela foi implementada como X-Content-Security-Policy no Firefox até a versão 23 e no IE até a versão 10, e foi implementada como X-Webkit-CSP no Chrome até a versão 25. Esses dois nomes foram substituídos pelo atual nome padrão Content Security Policy. Dada a quantidade de diretivas, dois nomes alternativos obsoletos, e a forma como várias ocorrências do mesmo cabeçalho e diretivas repetidas em um único cabeçalho são tratados, há uma alta probabilidade de que um desenvolvedor possa configurar mal esse cabeçalho.

Exemplo 1: O seguinte código define uma diretiva default-src excessivamente flexível e insegura:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy policy-directives="default-src '*'" />
        </headers>
    </http>

Antes do HTML5, os navegadores da Web forçavam a Política de Mesma Origem, que garante que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto o JavaScript quanto a página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e, depois, comunicá-las ao invasor. O HTML5 permite que o JavaScript acesse dados entre vários domínios quando um novo cabeçalho HTTP denominado Access-Control-Allow-Origin está definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.

Exemplo 1: Veja a seguir um exemplo de uso de um caractere curinga para especificar programaticamente os domínios com os quais o aplicativo tem permissão para se comunicar.

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

Usar * como o valor do cabeçalho Access-Control-Allow-Origin indica que os dados do aplicativo podem ser acessados pelo JavaScript em execução em qualquer domínio.