程序员通常信任隐藏字段的内容，认为用户不会查看它们或操作其内容。攻击者则会推翻这些假设。他们将检查写入隐藏字段的值，更改它们，或使用攻击数据替换这些内容。

示例：

  Hidden hidden = new Hidden(element);

如果隐藏字段包含敏感信息，那么就会像捕捉该页面的其余部分一样捕捉这些信息。这会导致敏感信息在用户不知情的情况下在浏览器缓存中被隐藏起来。

HTML5 的一项功能是在客户端 SQL 数据库存储数据。数据库名称是开始写入数据库或从数据库读取所需的重要信息。因此，数据库名称必须是每位用户特有的唯一字符串。如果数据库名称很容易被猜出，未经授权的人（例如其他用户）可能会窃取敏感数据或损坏数据库条目。
示例：以下代码使用了容易被猜出的数据库名称：

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

该代码可以成功运行，但任何能猜到数据库名称为 'mydb' 的人都可以访问该数据库。

内容安全策略 (CSP) 是声明性安全标头，允许开发人员规定站点可从哪些域中加载内容，或呈现在 Web 浏览器中时向哪些域发起连接。它提供额外的安全层以避免重大漏洞，如 Cross-Site Scripting、Clickjacking、Cross-origin Access 等，此外还有输入验证以及代码中的允许列表检验。但配置不恰当的标头无法提供此额外的安全层。该策略是在十五条指令的帮助下定义的，包括八条控制资源访问的指令，即：script-src、img-src、object-src、style_src、font-src、media-src、frame-src、connect-src。

其中的每个指令均将一个源列表作为值，指定站点可访问的域，以使用该指令涵盖的功能。开发人员可使用通配符 * 表示所有或部分数据源。所有的指令都不是强制性的。浏览器允许对未列出的指令使用所有的数据源，或者允许从可选 default-src 指令中衍生其值。此外，此标头的规范也在不断发展。在 Firefox V23 和 IE V10 以前，它作为 X-Content-Security-Policy 实现，在 Chrome V25 以前，它作为 X-Webkit-CSP 实现。这两个名称现在均已弃用，目前使用的标准名称为 Content Security Policy。鉴于指令数、两个弃用的备用名称以及在单个标头中相同标头和重复指令多次出现的处理方式，开发人员很有可能会错误地配置此标头。

请考虑以下错误配置方案：

- 带 unsafe-inline 或 unsafe-eval 的指令背离了 CSP 的初衷。
- 设置了 script-src 指令，但未配置脚本 nonce。
- 设置了 frame-src，但未配置 sandbox。
- 此标头的多个实例允许出现在同一响应中。开发团队和安全团队可能都设置了标头，但其中一个团队可能使用了一个弃用的名称。如果不存在具有最新名称（即，Content Security Policy）的标头，则使用弃用标头也没问题，但如果存在名为 content-security-header 的策略，则应忽略弃用的标头。旧版本只能理解弃用的名称，因此，为了获得所需的支持，响应包括具有全部三个名称的相同策略非常重要。
- 如果指令在同一个标头实例中重复出现，则会忽略所有后续的重复。

例 1：以下 django-csp 配置使用 unsafe-inline 和 unsafe-eval 不安全指令来支持内联脚本和代码评估：

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

内容安全策略 (CSP) 是声明性安全标头，允许开发人员规定站点可从哪些域中加载内容，或呈现在 Web 浏览器中时向哪些域发起连接。它提供额外的安全层以避免重大漏洞，如 Cross-Site Scripting、Clickjacking、Cross-origin Access 等，此外还有输入验证以及检查代码中的允许列表。

默认情况下，Spring Security 和其他框架不会添加内容安全策略标头。Web 应用程序作者必须声明一或多项安全策略，以针对受保护资源强制实施或监控，从而从额外的安全层获益。

允许将您的网站添加到框架会引发安全问题。例如，这可能引发 Clickjacking 漏洞或允许异常的跨框架通信。

默认情况下，Spring Security 等框架将 X-Frame-Options 标头包含在内，从而指示浏览器是否应对应用程序进行组帧。禁用或不设置此标头会引发与跨框架相关的漏洞。

示例 1：以下代码配置了受 Spring Security 保护的应用程序，以禁用 X-Frame-Options 标头：

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

内容安全策略 (CSP) 是声明性安全标头，使开发人员可以在浏览器中指定允许的安全相关行为，包括可从中检索内容的位置允许列表。它提供额外的安全层以避免重大漏洞，如 Cross-Site Scripting、Clickjacking、Cross-origin Access 等，此外还有输入验证以及检查代码中的允许列表。但配置不恰当的标头无法提供此额外的安全层。该策略是在 15 条指令的帮助下定义的，包括 8 条控制资源访问的指令：script-src、img-src、object-src、style_src、font-src、media-src、frame-src、connect-src。这 8 条指令将源列表作为值，该值指定站点可访问的域，以使用该指令涵盖的功能。开发人员可使用通配符 * 表示所有或部分数据源。其他源列表关键字（例如 'unsafe-inline' 和 'unsafe-eval'）提供了对脚本执行的更精细控制，但可能有害。所有的指令都不是强制性的。浏览器允许对未列出的指令使用所有的数据源，或者允许从可选 default-src 指令中衍生其值。此外，此标头的规范也在不断发展。在 Firefox V23 和 IE V10 以前，它作为 X-Content-Security-Policy 实现，在 Chrome V25 以前，作为 X-Webkit-CSP 实现。这两个名称现在均已弃用，目前使用的标准名称为 Content Security Policy。鉴于指令数、两个弃用的备用名称以及在单个标头中相同标头和重复指令多次出现的处理方式，开发人员很有可能会错误地配置此标头。

示例 1：以下代码设置了过度宽松且不安全的 default-src 指令：

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

在 HTML5 以前的版本中，Web 浏览器会强制实施同源策略，以确保在使用 JavaScript 访问 Web 页面内容时，JavaScript 和 Web 页面必须来自同一个域。如果不实施同源策略，恶意网站可能就会使用客户端凭据运行从其他网站加载敏感信息的 JavaScript，并对这些信息进行提炼，然后将其返回给攻击者。如果定义了名为 Access-Control-Allow-Origin 的新 HTTP 标头，HTML5 就支持使用 JavaScript 跨域访问数据。通过此标头，Web 服务器可定义允许使用跨源请求访问服务器域的其他域。但是，定义标头时应小心谨慎，如果 CORS 策略过于宽松，恶意应用程序就能趁机采用不当方式与受害者应用程序进行通信，从而导致发生欺骗、数据被盗、转发及其他攻击。

示例 1：以下示例会使用通配符以编程方式指定允许与应用程序进行通信的域。

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

使用 * 作为 Access-Control-Allow-Origin 标头的值，这表明任何域上运行的 JavaScript 都可以访问应用程序的数据。