关于 ITD

为什么会有这个平台

它源于运营者亲身经历的两起事故：在上线 AI 生成的代码后片刻，API 密钥就被盗用；以及一处配置失误导致机密文件被整体暴露。两者都算不上高明的攻击——都是本可避免的基础疏漏。

本平台将这些事故（已做匿名化处理）提炼为经验教训，并以你真正能落地执行的形式提供防御方法。

我们涵盖什么——又不涵盖什么

• 我们涵盖：如何防御、事故预防、术语的通俗解释、针对各类技术栈的安全配置，以及过往数据泄露事件的来龙去脉与教训。
• 我们不涵盖：攻击演示、漏洞利用代码、扫描他人站点，或规避检测的技术手法。ITD 不是攻击者的工具。

独立运营

本站独立运营，不与任何其他服务共享运营者信息、联系方式、分析数据或隐私政策。

编辑方针 — 以什么为依据

• 只以一手信息为依据。CVE 来自 NVD 与 CISA 的 KEV 目录，产品漏洞取自厂商自己的公告，设计准则参考 OWASP、NIST、MDN 等原典，并在每篇文章末尾注明出处。
• 不能断定的事情不断定。「目前尚未确认」与「没有发生」会分开表述；存在争议时并列各方说法并标注来源。
• 不刊登攻击步骤与验证代码（PoC）。基于同样的事实，我们只写「如何防御」。
• 涉及实名组织的文章只使用已公开的事实，不对责任下断言，也不点出个人姓名。

如何保持信息的新鲜度

安全信息一旦过时就会变成危害。漏洞类文章会显示「最后确认日期」，并且大约每两周将已发布的各个 CVE 与 CISA KEV 和 NVD 重新比对，确认上游是否发生变化。

事实更新时我们不只是改写，而是以更新记录保留「何时改了什么」。让读者能判断「这是哪个时点的信息」，与准确性同等重要。

错误的更正

如发现事实错误、过时信息或难以理解的说明，请附上该页面的 URL 发送至 contact@itdef.net。我们会核实并尽快修正，涉及内容的改动会记入更新记录。

同样的标准也用在自己身上

讲解安全的网站若疏于自身防护便说不过去。本站每天自动审计依赖包的已知漏洞并在当天处理，并把文章中推荐的安全响应头与配置同样应用于本站。