MySQL严格模式关闭的安全风险及STRICT_ALL_TABLES的安全意义咨询

嘿，这个问题问到点子上了，我来给你拆解清楚：

其实没法直接给你一个“百分之多少”的数字，这完全取决于你的CMS和业务场景：

• 如果是成熟的主流CMS（比如WP、Drupal这类），它们本身已经做了很完善的前端/后端输入校验，关闭严格模式的风险相对低，但绝对不是零——比如某些边缘场景下，CMS的校验没覆盖到，攻击者还是可能利用MySQL的自动转换特性搞事情。
• 如果是自定义或小众CMS，输入校验做得稀烂，那风险就很高了，相当于给攻击者开了个后门，让他们的恶意输入能被MySQL“默默修正”后存进数据库，进而触发各种逻辑漏洞。

很多人觉得它只是个开发辅助工具，但其实它在安全上的价值被低估了，核心是拒绝“静默数据篡改”：

• 防止超长字符串被截断：比如你表定义的是varchar(10)，攻击者输入15个字符的恶意内容，严格模式下直接报错拒绝；如果关闭严格模式，MySQL会自动截断成前10个字符——这可能导致原本的校验逻辑失效，比如CMS以为输入符合长度要求，但实际存的是截断后的恶意片段，绕过权限检查或者注入攻击。
• 避免无效数据进入系统：比如日期字段，严格模式下2023-02-30这种无效日期会直接报错；关闭的话会被转成0000-00-00，如果CMS依赖日期做业务逻辑（比如会员过期时间），这个无效日期可能被当成“永远有效”，导致权限不失效的安全问题。
• 强制数据类型一致性：比如int字段输入字符串，严格模式下直接报错；关闭的话会被转成0或NULL——攻击者可能利用这点，把恶意字符串转成0，绕过某些需要非零值的校验逻辑。

得辩证看：

• 短期来看，如果你用的是成熟CMS，关闭严格模式可能暂时没明显安全问题，但长远来看，严格模式是帮你提前发现潜在bug的工具——那些开启后出现的INSERT错误，本质是CMS代码没严格按照表结构处理数据，这些bug说不定哪天就变成安全漏洞。
• 如果你用的是小众/自定义CMS，风险绝对不低，因为MySQL的自动转换会帮攻击者掩盖恶意输入的问题，让他们的攻击更容易成功。

我的建议是：不要为了迁就CMS的代码问题而关闭严格模式，反而应该针对那些INSERT错误去修复CMS的代码——比如把空字符串转成合法的默认值，或者修正日期格式，这才是从根源上解决问题，同时提升系统的安全性和稳定性。

内容的提问来源于stack exchange，提问作者chingNotCHing