好吧，将安全性构建到框架中并不是一件容易的事。以您提到的 XSS 保护为例。Web 应用程序安全性的当前趋势表明，处理注入缺陷需要三件事：

• 输入验证
• 输出验证
• 上下文感知输出转义（不是一件容易的事）！

即使在处理上述所有服务器端时，当易受攻击的 Javascript 代码被引入应用程序时，您仍然可能容易受到 DOM XSS 攻击（例如，jQuery 也可能引入 DOM XSS）。

就个人而言，我认为框架中最重要但经常被忽视的特性是安全默认值和安全代码示例。开发人员经常复制和粘贴代码或将设置保留为默认值。因此，如果您要引入令牌作为 CSRF 保护，请默认将它们添加到每个表单中，并允许在代码/配置中将其关闭。

如果您正在寻找某种安全框架清单，曾经有一个 OWASP 项目（现已关闭） - Web Application Security Manifesto。它旨在提供这样的测试，并且是目前最好的清单。还可以浏览各种OWASP 备忘单，以帮助您实施每个安全控制。

我建议为其添加反自动化措施。框架的用户可以选择他想要使用此功能保护的页面（例如登录页面或反馈表）。如果攻击者多次提交表单，他将面临每个后续请求的验证码，基于他的 IP（不是会话 ID！）。

此外，会话处理是一项乏味的任务。该框架应确保：

不接受用户生成的会话 这是为了防止会话劫持，其中攻击者生成会话 ID 供其他人使用

身份验证后会重新生成会话 ID， 这样当攻击者成功说服受害者使用某个会话 ID 时，攻击者将不会在受害者登录时拥有经过身份验证的会话

经过身份验证的会话的会话 ID 永远不会通过 HTTP 传输 但对所有经过身份验证的内容使用 SSL

会话 cookie 具有正确的标志 HttpOnly 和经过身份验证的会话的安全标志

此外，我建议框架允许开发人员设置缓存策略。对于提供给经过身份验证的用户的页面，可能包含隐私敏感数据，缓存应该很容易（甚至默认）关闭。

Oh joy - 另一个 PHP 框架。请原谅我的讽刺，但是已经有大量的框架在野外漂浮。大多数都臃肿、缓慢且充满安全漏洞。但至少您正在尝试预先解决安全问题。

我想说一个框架是否应该提供它自己的数据库抽象层是有问题的。例如，有时活动记录模式很有用，但并非总是如此。

到目前为止，最有价值的安全附加组件是保证向后兼容性，以鼓励您的用户群在您发布新版本时进行升级。

根据我在其他地方的评论，验证不是安全问题 - 数据的正确表示是。提供一种简单的机制来在不同目标的表示之间以及与目标中性格式之间进行更改（这通常意味着对 base64 编码进行一些调整）会很好。

然而，验证功能问题并不是一件坏事——例如，确保预订的出发日期在抵达日期之后。

日志记录非常重要。

文件 I/O 的沙盒化值得考虑。

正如克里斯所说 - 您应该防止会话劫持/固定。

您可能会考虑提供一个身份验证框架（毕竟，如果您有 ACL，那么您已经对身份验证的实现方式施加了一些限制）。

如果您想要一个真正安全的框架，那么请考虑如何实现不可搜索的会话（我为此提出的唯一解决方案依赖于守护进程来进行权限分离 - 因此完全不适合大多数想要保护的人会话数据 - 即廉价共享主机包上的数据）。

安全域之外还有很多其他的东西——例如异步消息支持。但请记住，每次添加更多功能时，您可能会拒绝使用与您自己的框架一起使用的补充框架的能力（例如 smarty、seagull、教义在特定领域都非常有能力）

输入验证规则引擎。（以及就此而言的输出）