前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载本指南以开源仓库 vulnerability-scanner 技能 中提供的安全审计清单Security Checklists为核心骨架逐条讲解 OWASP Top 10、认证、API、数据保护、安全响应头与快速审计命令的落地方式并结合 Dillinger 仓库gh_mirrors/di/dillinger的真实源码印证每类检查项的实践形态。读完本文你将得到一份可直接复制进安全报告或 PLAN.md 的可执行检查单并掌握如何在真实 Next.js 全栈项目中验证访问控制、密钥管理、API 鉴权与配置加固。清单文档定位审计的“待办事项表”checklists.md 是整个 vulnerability-scanner 技能体系中的速查层与 SKILL.md 的原则层、scripts/security_scan.py 的自动化验证层形成三层配合SKILL.md提供安全专家思维、OWASP 2025 风险分类、供应链安全、攻击面测绘、风险优先级判定等“方法论”checklists.md把方法论压缩成可勾选的“待办事项”供审计者在代码审查、发布前巡检、威胁建模时逐项核对security_scan.py用python security_scan.py project_path自动执行依赖、密钥、危险模式、配置四类扫描输出 JSON 审计报告用于验证清单中的检查项是否真正落实。文档末尾明确指出其用法将相关清单复制进你的 PLAN.md 或安全报告中 Usage: Copy relevant checklists into your PLAN.md or security report.。因此本文按同样顺序展开并在每一节补充 Dillinger 仓库中的对应实现证据。OWASP Top 10 审计清单A01访问控制失效Broken Access Control所有受保护路由均做授权校验Authorization on all protected routes默认拒绝策略Deny by default已实现速率限制Rate limiting implementedCORS 配置正确CORS properly configured在 Dillinger 中“受保护路由授权”的典型实现是 API 层统一鉴权中间件lib/api-auth.ts 中的validateApiKey(request)会先检查服务端是否配置了DILLINGER_API_KEY环境变量未配置返回503再校验请求头中的Authorization: Bearer api-key缺失返回401不匹配返回403。这一函数被 app/api/v1/convert/route.ts、app/api/v1/render/route.ts、app/api/v1/export/html/route.ts、app/api/v1/export/pdf/route.ts、app/api/v1/webhooks/route.ts等所有 v1 接口统一调用属于“默认拒绝、显式放行”的写法。而 OAuth 类回调路由如app/api/github/callback/route.ts、app/api/dropbox/callback/route.ts、app/api/google-drive/oauth/route.ts等则依赖各自云服务的授权码交换流程属于另一套以服务端凭证为信任锚点的鉴权模型。A02加密失败Cryptographic Failures密码使用 bcrypt/argon2 哈希成本因子 ≥ 12Passwords hashed, cost 12敏感数据静态加密Sensitive data encrypted at rest所有连接启用 TLS 1.2TLS 1.2 for all connections代码与日志中无密钥泄露No secrets in code/logs从源码结构看Dillinger 本身不维护用户密码体系其身份认证全部委托给第三方 OAuthGitHub、Dropbox、Google Drive、OneDrive、Bitbucket 等因此“密码哈希成本因子”主要适用于自建账号体系的场景而“密钥不进代码”在本仓库中是硬性约束——所有云服务凭证均通过环境变量注入参见 lib/env.ts 对NEXT_PUBLIC_APP_URL/NEXT_PUBLIC_BASE_URL的读取模式以及lib/api-auth.ts中对DILLINGER_API_KEY的读取。审计时可用下方“快速审计命令”中的密钥扫描正则确认api_key、token、password、AKIA...等模式未出现在源码或提交记录中。A03注入Injection参数化查询Parameterized queries对所有用户输入做校验Input validation on all user data输出编码防 XSSOutput encoding for XSS无 eval() 或动态代码执行No eval() or dynamic code execution仓库证据app/api/v1/convert/route.ts在接收 HTML 输入时做了严格校验——typeof html ! string || !html.trim()时直接返回400随后才交给 Turndown 服务转换体现了“先校验、后处理”的输入验证模式。输出侧lib/document.ts的sanitizeDownloadFilenamelib/document.ts将导出文件名中所有非a-zA-Z0-9._-字符替换为下划线防止文件名注入/路径穿越lib/export.ts在生成下载文件名时同样先经过该函数清洗再拼接扩展名。前端渲染 Markdown 预览的MarkdownPreview组件与编辑器侧需要特别注意dangerouslySetInnerHTML类用法这是 A03 输出编码检查在 React/Next.js 项目中的重点关注点。A04不安全设计Insecure Design已完成威胁建模Threat modeling done已定义安全需求Security requirements defined业务逻辑已校验Business logic validated威胁建模的四个标准提问资产是什么、谁会攻击、如何攻击、影响多大正是 SKILL.md 中“Security Expert Mindset”一节的要求也是安全审计员 agentsecurity-auditor.md每次审查前的固定动作。对 Dillinger 而言业务逻辑校验的典型场景包括文档导入导出的扩展名/内容一致性、OAuth 回调状态参数防 CSRF、API 请求体字段类型校验等。A05安全配置错误Security Misconfiguration禁用不必要功能Unnecessary features disabled错误信息已净化Error messages sanitized已配置安全响应头Security headers configured默认凭据已更改Default credentials changedsecurity_scan.py的scan_configuration()会自动检查DEBUG: true、debug True、NODE_ENVdevelopment、CORS_ALLOW_ALLtrue、Access-Control-Allow-Origin: *以及allowCredentials origin: *的危险组合同时检测是否存在next.config.js/next.config.mjs/middleware.ts/nginx.conf中的安全响应头配置缺失会给出 medium 级“No security headers configuration found”建议。Dillinger 的 next.config.mjs 目前仅包含包导入优化与服务端组件外部包声明未配置响应头——若直接部署生产环境应结合下文“安全响应头”一节补充 CSP/HSTS 等配置。A06易受攻击和过时的组件Vulnerable and Outdated Components依赖保持最新Dependencies up to date无已知漏洞No known vulnerabilities移除未使用依赖Unused dependencies removed对应security_scan.py的scan_dependencies()它先检查 npm/yarn/pnpm/pip 的锁文件是否存在缺失判为 high 级“Missing Lock File供应链完整性风险”再在存在package.json时执行npm audit --json按 critical/high/moderate/low 统计漏洞并设置总体状态。Dillinger 仓库根目录同时存在 package.json 与 package-lock.json锁文件已提交满足“锁文件完整性”要求定期运行npm audit即为该项清单的落地动作。A07身份认证失效Identification and Authentication Failures提供 MFAMFA available登出时会话失效Session invalidation on logout已实现会话超时Session timeout implemented暴力破解防护Brute force protectionDillinger 的认证全部走 OAuth 第三方身份提供商GitHub、Dropbox、Google Drive、OneDrive、Bitbucket 的 oauth/callback/unlink 路由MFA 与暴力破解防护天然由 IdP 承担仓库侧需要审计的是令牌只保存在服务端/内存态、回调状态参数校验、unlink路由能正确清除本地会话与令牌。A08软件与数据完整性失效Software and Data Integrity Failures依赖完整性已验证Dependency integrity verifiedCI/CD 流水线已加固CI/CD pipeline secured更新机制已加固Update mechanism secured锁文件package-lock.json提交、npm audit定期执行、构建产物签名与发布管道权限控制是 A08 的常见落地项SKILL.md 的供应链安全章节还强调“验证包完整性校验和、锁定版本、关键依赖使用私有源、签名并验证构件”。A09日志与告警失效Security Logging and Monitoring Failures安全事件已记录Security events logged日志已受保护Logs protected日志中无敏感数据No sensitive data in logs已配置告警Alerting configured注意security_scan.py的密钥扫描会覆盖.env*等配置文件CONFIG_EXTENSIONS包含.env、.env.local、.env.development这正是“日志/配置中不得出现明文密钥”的反向验证一旦密钥模式出现在可被读取的文件中即判为 critical/high。审计时同样要检查生产日志输出是否过滤了 Authorization 头与回调参数。A10服务端请求伪造 SSRFServer-Side Request Forgery已实现 URL 校验URL validation implemented外部调用使用白名单Allow-list for external calls已做网络分段Network segmentationDillinger 中的 SSRF 关注点集中在 PDF 导出vercel.json 中app/api/export/pdf/route.ts依赖sparticuz/chromium无头浏览器渲染以及图片上传app/api/upload/image/route.ts等“服务器主动发起请求/渲染外部内容”的功能点需确认目标 URL 校验与协议白名单。认证清单Authentication Checklist强密码策略Strong password policy账户锁定Account lockout安全密码重置Secure password reset会话管理Session management令牌过期Token expiration登出失效Logout invalidation对 Dillinger 这类纯 OAuth 应用“强密码/锁定/重置”三项由 GitHub、Google 等 IdP 保证仓库自身的会话管理责任在于OAuth 令牌的生命周期与过期处理、unlink路由正确执行登出与令牌清除、各云服务status路由app/api/github/status/route.ts、app/api/dropbox/status/route.ts等如实反映连接状态。API 层则通过 Bearer Token 鉴权见 app/api/v1/openapi/route.ts 的securitySchemes.bearerAuth声明实现令牌化访问。API 安全清单API Security Checklist必须认证Authentication required每个端点独立授权Authorization per endpoint输入校验Input validation速率限制Rate limiting输出净化Output sanitization错误处理Error handlingDillinger 的 v1 API 是清单的教科书式对应所有端点/api/v1/convert、/api/v1/render、/api/v1/export/html、/api/v1/export/pdf、/api/v1/webhooks都在处理业务前先调用validateApiKey(request)完成“必须认证”convert端点对请求体做类型与空值校验400convert的 catch 分支返回通用错误文案Failed to convert HTML to markdown500避免泄露内部异常细节即“错误处理”与“输出净化”的体现。OpenAPI 规范在 app/api/v1/openapi/route.ts 中完整声明了 bearerAuth 安全方案可供审计者对照端点逐个核验授权。数据保护清单Data Protection Checklist静态加密Encryption at rest传输加密Encryption in transit密钥管理Key management数据最小化Data minimization安全删除Secure deletionDillinger 文档数据主要托管于第三方云盘Dropbox、Google Drive、OneDrive、Bitbucket、GitHub 仓库因此“静态加密/密钥管理”由云服务商与平台密钥体系共同承担仓库侧可验证的是OAuth 令牌是否仅存于服务端环境、DILLINGER_API_KEY是否通过环境变量而非硬编码注入、导出下载文件名是否经sanitizeDownloadFilename净化数据最小化与安全处理的实践。安全响应头速查表Security HeadersHeaderPurpose清单原文审计关注点Content-Security-PolicyXSS prevention是否限制 script-src / connect-src是否允许内联脚本X-Content-Type-OptionsMIME sniffing是否设置为nosniffX-Frame-OptionsClickjacking是否设置DENY/SAMEORIGIN或使用 CSPframe-ancestorsStrict-Transport-SecurityForce HTTPS生产环境是否强制 HSTS 与 TLS 1.2Referrer-PolicyReferrer control是否限制跨域 Referrer 泄露security_scan.py的配置扫描器会专门查找next.config.js/next.config.mjs/middleware.ts/nginx.conf中是否存在安全响应头配置在 Next.js 中通常建议在next.config.mjs的headers()或中间件中统一注入以上响应头。快速审计命令Quick Audit CommandsCheckWhat to Look For清单原文对应仓库/工具证据Secrets in codepassword, api_key, secretsecurity_scan.py的SECRET_PATTERNS覆盖 API Key、Token、Bearer、AWS/Azure/GCP 凭据、数据库连接串、私钥、JWT 等 12 类正则Dangerous patternseval, innerHTML, SQL concatDANGEROUS_PATTERNS覆盖 eval/exec/Function、child_process.exec、subprocess shellTrue、dangerouslySetInnerHTML、innerHTML、SQL 字符串拼接/f-string、verifyFalse、不安全 pickle/yaml 等 15 类模式Dependency issuesnpm audit, snykscan_dependencies()自动执行npm audit --json并统计 critical/high/moderate/low实际执行来自 security_scan.py 的 CLI 定义# 全量扫描依赖 密钥 代码模式 配置输出 JSON 报告 python .agent/skills/vulnerability-scanner/scripts/security_scan.py project_path # 仅扫描某类风险 python .agent/skills/vulnerability-scanner/scripts/security_scan.py project_path --scan-type deps python .agent/skills/vulnerability-scanner/scripts/security_scan.py project_path --scan-type secrets python .agent/skills/vulnerability-scanner/scripts/security_scan.py project_path --scan-type patterns python .agent/skills/vulnerability-scanner/scripts/security_scan.py project_path --scan-type config # 输出人类可读的摘要而非 JSON python .agent/skills/vulnerability-scanner/scripts/security_scan.py project_path --output summary--scan-type支持all|deps|secrets|patterns|config默认all--output支持json|summary默认json。扫描器默认跳过node_modules、.git、dist、build、__pycache__、.venv、venv、.next等目录代码文件覆盖.js/.ts/.jsx/.tsx/.py/.go/.java/.rb/.php配置文件覆盖.json/.yaml/.yml/.toml/.env*。汇总时只要存在 critical 即判定[!!] CRITICAL ISSUES FOUND否则依次降级为 HIGH / REVIEW RECOMMENDED / SECURE。如何把清单落进真实项目以 Dillinger 为例结合上文一次完整的审计巡检可以这样编排威胁建模按 SKILL.md 的四个提问界定 Dillinger 的资产用户文档、OAuth 令牌、DILLINGER_API_KEY、攻击者匿名爬虫、恶意第三方应用与入口点v1 API、OAuth 回调、上传/导出端点。自动扫描运行security_scan.py全量扫描重点核对 A03锁文件 npm audit、A04密钥泄露、A05危险代码模式、A02调试/开发模式、CORS 配置。人工核验清单逐项检查 A01 的“所有 v1 路由是否都调用了validateApiKey”、A05 的“安全响应头是否已在 next.config.mjs/middleware 配置”、A07 的“OAuth 回调与 unlink 会话处理”、A10 的“PDF 导出/图片上传的 URL 校验”。输出报告将勾选结果连同security_scan.py的 JSON/摘要输出一起复制进 PLAN.md 或安全报告按“Critical/High/Medium/Low”分级列出修复项——这与清单文档的 Usage 说明一致。关键提醒清单只负责“发现问题”优先级决策仍需结合 CVSS、EPSS 与资产价值参考 SKILL.md 的风险决策树EPSS 0.5 即 CRITICAL否则看 CVSS 分级并始终追问一句“攻击者会拿这个做什么”赞分享前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载相关推荐ag-kit 漏洞扫描安全检查清单基于 OWASP Top 10:2025 的 Agent 化安全审计实战指南ag kit 漏洞扫描安全检查清单基于 OWASP Top 10:2025 的 Agent 化安全审计实战指南 本文以 ag kit 仓库中 .agents/人工智能AI 技能agentic-awesome-skills 007 技能实战OWASP Top 10 三清单Web / API / LLM安全审计速查手册agentic awesome skills 007 技能实战OWASP Top 10 三清单Web / API / LLM安全审计速查手册 本文以 agAI 技能AI 插件Dillinger API 安全测试实战指南基于 OWASP API Top 10 的认证、授权与输入验证测试方法论Dillinger API 安全测试实战指南基于 OWASP API Top 10 的认证、授权与输入验证测试方法论 本指南以 .agent/skills/a前端开发工具上一篇一个脚本打通八大网盘直链下载Online-disk-direct-link-download-assistant 免费实战指南下一篇douyin-downloader 视频保存终极指南从第一条无水印下载到完整内容管理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考