Back to Details

security-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Security Review

安全审查

Evaluate your application's security posture against industry standards and validate findings through browser-based penetration testing. This review covers the attack surface that static analysis tools miss — runtime behavior, header configuration, authentication flows, and client-side vulnerabilities.
基于行业标准评估您的应用安全态势，并通过基于浏览器的渗透测试验证发现的问题。本次审查覆盖静态分析工具遗漏的攻击面——运行时行为、头配置、身份验证流程及客户端漏洞。

When to use

适用场景

Use 
/security-review
when:
  • Before launching a new application or feature
  • After adding authentication or authorization changes
  • When handling sensitive data (user credentials, payment info, PII)
  • Preparing for a security audit
  • After a security incident to check for similar issues
  • Reviewing third-party integrations
在以下场景使用
/security-review
：
  • 新应用或新功能上线前
  • 添加身份验证或授权变更后
  • 处理敏感数据（用户凭证、支付信息、个人可识别信息PII）时
  • 准备安全审计时
  • 发生安全事件后检查同类问题时
  • 审查第三方集成时

Standards Referenced

参考标准

  • OWASP Top 10 (2021) — Top web application security risks
  • OWASP ASVS v4.0 — Application Security Verification Standard
  • OWASP Session Management Cheat Sheet
  • NIST 800-63B — Digital Identity Guidelines (authentication)
  • CWE/SANS Top 25 — Most Dangerous Software Weaknesses
  • Mozilla Observatory — HTTP security header best practices
  • OWASP Top 10 (2021) — 顶级Web应用安全风险
  • OWASP ASVS v4.0 — 应用安全验证标准
  • OWASP Session Management Cheat Sheet（OWASP会话管理速查表）
  • NIST 800-63B — 数字身份指南（身份验证）
  • CWE/SANS Top 25 — 最危险的软件弱点
  • Mozilla Observatory — HTTP安全头最佳实践

Phase Overview

阶段概述

Phase 1: EDUCATE   → Security context and what we check
Phase 2: SCOPE     → Identify attack surface, auth mechanisms, data flows
Phase 3: ANALYZE   → Automated checks + browser-based penetration testing
Phase 4: REPORT    → Findings with evidence, CVE references, confidence scores
Phase 5: REMEDIATE → Fix guidance + YAML regression tests
Phase 1: EDUCATE   → 安全背景及检查范围说明
Phase 2: SCOPE     → 识别攻击面、认证机制、数据流
Phase 3: ANALYZE   → 自动化检查 + 基于浏览器的渗透测试
Phase 4: REPORT    → 包含证据、CVE参考、置信度评分的发现报告
Phase 5: REMEDIATE → 修复指南 + YAML回归测试

Phase 1: Educate

第一阶段：背景说明

Why this matters: The average cost of a data breach is $4.45M (IBM 2023). 83% of web applications have at least one critical vulnerability. Many security issues are only detectable at runtime — misconfigured headers, insecure token storage, broken access controls — which is exactly what browser-based testing catches.
This review checks your app against objective security criteria with browser-based validation. Every finding references a specific standard (OWASP, CWE, NIST).
重要性： 数据泄露的平均成本为445万美元（IBM 2023年数据）。83%的Web应用存在至少一个严重漏洞。许多安全问题仅能在运行时检测到——配置错误的头、不安全的令牌存储、失效的访问控制——而这正是基于浏览器的测试所能捕获的内容。
本次审查通过基于浏览器的验证，对照客观安全标准检查您的应用。每项发现均引用特定标准（OWASP、CWE、NIST）。

Phase 2: Scope

第二阶段：范围界定

Gather context

收集上下文信息

  1. Auto-detect from codebase:
    • Authentication mechanism (JWT, sessions, OAuth, API keys)
    • Framework security features in use (CSRF tokens, CORS config, CSP)
    • Dependencies with known vulnerabilities (
      npm audit
      / 
      pip audit
      )
    • API routes and endpoints
    • Environment variable handling
    • File upload capabilities
    • Third-party scripts and CDN usage
  2. Ask the user (one at a time):
    • Target URL: Where is the app running?
    • Auth mechanism: How do users log in? (auto-detected, confirm)
    • Test credentials: Do you have test accounts I can use? (needed for authenticated testing)
    • Sensitive data: What sensitive data does the app handle? (PII, payments, health records)
    • Known concerns: Any specific areas you're worried about? (optional)
  3. Map the attack surface:
    • List all user input points (forms, URL params, file uploads, WebSocket messages)
    • List all API endpoints with their auth requirements
    • List all third-party integrations
    • Identify data flow: where does sensitive data enter, process, store, and exit?
  1. 从代码库自动检测：
    • 身份验证机制（JWT、会话、OAuth、API密钥）
    • 正在使用的框架安全功能（CSRF令牌、CORS配置、CSP）
    • 存在已知漏洞的依赖项（
      npm audit
      / 
      pip audit
      ）
    • API路由和端点
    • 环境变量处理方式
    • 文件上传功能
    • 第三方脚本和CDN使用情况
  2. 向用户确认（逐一询问）：
    • 目标URL：应用部署在哪里？
    • 认证机制：用户如何登录？（已自动检测，请确认）
    • 测试凭证：是否有可供使用的测试账号？（用于已认证测试）
    • 敏感数据：应用处理哪些敏感数据？（PII、支付信息、健康记录）
    • 已知隐患：是否有特定担忧的领域？（可选）
  3. 绘制攻击面：
    • 列出所有用户输入点（表单、URL参数、文件上传、WebSocket消息）
    • 列出所有带认证要求的API端点
    • 列出所有第三方集成
    • 识别数据流：敏感数据的输入、处理、存储和输出路径

Phase 3: Analyze

第三阶段：分析

Open a browser session with 
new_session
using 
record_evidence: true
. Run all applicable check categories.
使用
new_session
打开浏览器会话，设置
record_evidence: true
。运行所有适用的检查类别。

Category A: HTTP Security Headers (HDR)

类别A：HTTP安全头（HDR）

Check IDCheckStandardMethod
HDR-01Content-Security-Policy header present and restrictiveOWASP A05Inspect response headers
HDR-02Strict-Transport-Security (HSTS) with long max-ageOWASP TransportCheck header presence and value
HDR-03X-Content-Type-Options: nosniffMozilla ObservatoryCheck header
HDR-04X-Frame-Options or CSP frame-ancestorsOWASP ClickjackingCheck header
HDR-05Referrer-Policy set appropriatelyPrivacy/SecurityCheck header value
HDR-06Permissions-Policy restricts sensitive APIsBrowser securityCheck camera, microphone, geolocation policies
HDR-07No Server/X-Powered-By version disclosureInformation leakCheck for version strings in headers
HDR-08Cache-Control for sensitive pagesOWASP SessionCheck no-store for authenticated content
HDR-09CORS not overly permissiveOWASP A05Check Access-Control-Allow-Origin
HDR-10No mixed content (HTTP resources on HTTPS page)Transport securityInspect all resource URLs
Browser validation: Use JavaScript via 
act
to inspect 
document.querySelector('meta[http-equiv]')
and fetch response headers via a same-origin request. Use 
get_browser_console_logs
to check for mixed content warnings.
检查ID检查内容参考标准方法
HDR-01存在且严格的Content-Security-Policy头OWASP A05检查响应头
HDR-02带有长max-age的Strict-Transport-Security (HSTS)OWASP Transport检查头的存在性及值
HDR-03X-Content-Type-Options: nosniffMozilla Observatory检查头
HDR-04X-Frame-Options或CSP frame-ancestorsOWASP Clickjacking检查头
HDR-05合理设置Referrer-Policy隐私/安全检查头的值
HDR-06Permissions-Policy限制敏感API浏览器安全检查摄像头、麦克风、地理位置策略
HDR-07不泄露Server/X-Powered-By版本信息信息泄露检查头中的版本字符串
HDR-08敏感页面的Cache-Control设置OWASP Session检查已认证内容是否设置no-store
HDR-09CORS设置不过于宽松OWASP A05检查Access-Control-Allow-Origin
HDR-10无混合内容（HTTPS页面加载HTTP资源）传输安全检查所有资源URL
浏览器验证： 通过
act
执行JavaScript，检查
document.querySelector('meta[http-equiv]')
，并通过同源请求获取响应头。使用
get_browser_console_logs
检查混合内容警告。

Category B: Authentication & Session Management (AUTH)

类别B：身份验证与会话管理（AUTH）

Check IDCheckStandardMethod
AUTH-01Tokens not stored in localStorageOWASP ASVS 3.3.2Check localStorage/sessionStorage for tokens
AUTH-02Session cookies have HttpOnly flagOWASP SessionInspect Set-Cookie headers
AUTH-03Session cookies have Secure flagOWASP SessionInspect Set-Cookie headers
AUTH-04Session cookies have SameSite attributeOWASP CSRFInspect Set-Cookie headers
AUTH-05Session expires after idle timeoutOWASP ASVS 3.3.1Wait and verify session invalidation
AUTH-06Logout invalidates server-side sessionOWASP ASVS 3.3.1Logout, replay old token, check response
AUTH-07Password reset tokens are single-useOWASP AuthUse reset link twice, verify second fails
AUTH-08No credentials in URL parametersOWASP TransportCheck URL for tokens/passwords
AUTH-09Brute force protection on loginOWASP AuthAttempt multiple failed logins, check for lockout/rate-limit
AUTH-10CSRF protection on state-changing requestsOWASP A01Submit forms without CSRF token
AUTH-11JWT signature verified (if applicable)OWASP AuthSend modified JWT, check rejection
AUTH-12OAuth state parameter used (if applicable)OWASP AuthCheck OAuth flow for state param
Browser validation: Log in via 
act
, inspect cookies with JavaScript (
document.cookie
— HttpOnly cookies won't appear, which is correct). Check localStorage. Perform logout, replay requests. Attempt brute force (5 wrong passwords). Modify JWT tokens and test.
检查ID检查内容参考标准方法
AUTH-01令牌未存储在localStorage中OWASP ASVS 3.3.2检查localStorage/sessionStorage中的令牌
AUTH-02会话Cookie带有HttpOnly标志OWASP Session检查Set-Cookie头
AUTH-03会话Cookie带有Secure标志OWASP Session检查Set-Cookie头
AUTH-04会话Cookie带有SameSite属性OWASP CSRF检查Set-Cookie头
AUTH-05会话闲置超时后过期OWASP ASVS 3.3.1等待并验证会话失效
AUTH-06登出会使服务器端会话失效OWASP ASVS 3.3.1登出后重放旧令牌，检查响应
AUTH-07密码重置令牌仅可使用一次OWASP Auth两次使用重置链接，验证第二次失败
AUTH-08URL参数中无凭证信息OWASP Transport检查URL中的令牌/密码
AUTH-09登录存在暴力破解防护OWASP Auth尝试多次失败登录，检查锁定/速率限制
AUTH-10状态变更请求带有CSRF防护OWASP A01无CSRF令牌时提交表单
AUTH-11JWT签名已验证（如适用）OWASP Auth发送修改后的JWT，检查是否被拒绝
AUTH-12OAuth流程使用state参数（如适用）OWASP Auth检查OAuth流程中的state参数
浏览器验证： 通过
act
登录，使用JavaScript（
document.cookie
—— HttpOnly Cookie不会显示，此为正常情况）检查Cookie。检查localStorage。执行登出并重放请求。尝试暴力破解（5次错误密码）。修改JWT令牌并测试。

Category C: Input Validation & Injection (INJ)

类别C：输入验证与注入（INJ）

Check IDCheckStandardMethod
INJ-01XSS: reflected input in pageOWASP A03 / CWE-79Submit 
<script>alert(1)</script>
in all inputs, check if rendered
INJ-02XSS: stored input from databaseOWASP A03 / CWE-79Submit script via form, check if rendered on subsequent page loads
INJ-03SQL injection in form inputsOWASP A03 / CWE-89Submit 
' OR '1'='1
patterns, check for errors
INJ-04Open redirect via URL parametersCWE-601Test redirect params with external URLs
INJ-05Path traversal in file operationsCWE-22Test 
../../etc/passwd
in file-related params
INJ-06Command injection in input fieldsCWE-78Test 
; ls
or `
INJ-07HTML injection in user contentCWE-79Submit HTML tags, check if rendered
INJ-08URL scheme validation (javascript:)CWE-79Test 
javascript:alert(1)
in URL inputs
INJ-09File upload validationOWASP A04Upload files with wrong extensions, oversized files, executable content
INJ-10API input validationOWASP A03Send malformed JSON, missing fields, wrong types to API endpoints
Browser validation: Use 
act
to fill form fields with test payloads. Capture page state after submission. Check for script execution, error messages, unexpected behavior. Use 
get_browser_console_logs
for JavaScript errors that indicate injection vectors.
Important: These are non-destructive test payloads for detection only. Do not attempt actual exploitation. Alert-based XSS tests use 
alert(1)
which is harmless.
检查ID检查内容参考标准方法
INJ-01XSS：输入在页面中反射OWASP A03 / CWE-79在所有输入框提交
<script>alert(1)</script>
，检查是否渲染
INJ-02XSS：输入存储在数据库中OWASP A03 / CWE-79通过表单提交脚本，检查后续页面加载时是否渲染
INJ-03表单输入中的SQL注入OWASP A03 / CWE-89提交
' OR '1'='1
模式，检查是否报错
INJ-04URL参数导致的开放重定向CWE-601使用外部URL测试重定向参数
INJ-05文件操作中的路径遍历CWE-22在文件相关参数中测试
../../etc/passwd
INJ-06输入字段中的命令注入CWE-78在可能进入shell的输入中测试
; ls
或`
INJ-07用户内容中的HTML注入CWE-79提交HTML标签，检查是否渲染
INJ-08URL scheme验证（javascript:）CWE-79在URL输入中测试
javascript:alert(1)
INJ-09文件上传验证OWASP A04上传错误扩展名、过大文件、可执行内容
INJ-10API输入验证OWASP A03向API端点发送格式错误的JSON、缺失字段、错误类型数据
浏览器验证： 使用
act
在表单字段中填入测试载荷。提交后捕获页面状态。检查脚本执行、错误信息、异常行为。使用
get_browser_console_logs
查看指示注入向量的JavaScript错误。
注意： 这些仅为用于检测的非破坏性测试载荷，不尝试实际利用。基于alert的XSS测试使用
alert(1)
，无危害。

Category D: Access Control (AC)

类别D：访问控制（AC）

Check IDCheckStandardMethod
AC-01Authenticated pages return 401/403 without authOWASP A01Access protected URLs without authentication
AC-02No IDOR (Insecure Direct Object Reference)OWASP A01 / CWE-639Change resource IDs in URLs, check for unauthorized access
AC-03API endpoints enforce authorizationOWASP A01Call API endpoints with wrong/missing auth
AC-04Admin pages are not accessible to regular usersOWASP A01Navigate to admin routes with regular user session
AC-05No sensitive data in client-side sourceInformation leakCheck JavaScript bundles for API keys, secrets
AC-06Directory listing disabledInformation leakAccess directory URLs (e.g., /api/, /static/)
AC-07Debug endpoints not exposed in productionOWASP A05Check common debug paths (/debug, /trace, /graphql playground)
AC-08Error messages don't leak internal detailsOWASP A05Trigger errors, check for stack traces, DB details
Browser validation: Navigate to protected pages without auth. Try accessing resources belonging to other users. Check JavaScript source for hardcoded secrets using 
act
with JavaScript to scan script contents.
检查ID检查内容参考标准方法
AC-01未认证时访问已认证页面返回401/403OWASP A01无认证时访问受保护URL
AC-02无IDOR（不安全直接对象引用）OWASP A01 / CWE-639修改URL中的资源ID，检查是否可未授权访问
AC-03API端点强制执行授权OWASP A01使用错误/缺失的认证调用API端点
AC-04普通用户无法访问管理员页面OWASP A01使用普通用户会话导航至管理员路由
AC-05客户端源码中无敏感数据信息泄露检查JavaScript包中的API密钥、机密信息
AC-06禁用目录列表信息泄露访问目录URL（如/api/、/static/）
AC-07生产环境未暴露调试端点OWASP A05检查常见调试路径（/debug、/trace、/graphql playground）
AC-08错误信息不泄露内部细节OWASP A05触发错误，检查是否有堆栈跟踪、数据库细节
浏览器验证： 无认证时导航至受保护页面。尝试访问属于其他用户的资源。使用
act
执行JavaScript扫描脚本内容，检查客户端源码中的硬编码机密。

Category E: Client-Side Security (CLI)

类别E：客户端安全（CLI）

Check IDCheckStandardMethod
CLI-01No sensitive data in client-side storageOWASP StorageInspect localStorage, sessionStorage, IndexedDB
CLI-02Subresource Integrity (SRI) on CDN resourcesSupply chainCheck 
integrity
attribute on external scripts/styles
CLI-03Third-party scripts inventorySupply chainList all external script sources
CLI-04No eval() or innerHTML with user inputCWE-79Scan JavaScript for dangerous patterns
CLI-05Service worker scope is restrictedClient securityCheck SW registration scope
CLI-06WebSocket connections use WSSTransportCheck WS connection URLs
CLI-07No sensitive data in console logsInformation leakCheck 
get_browser_console_logs
output
CLI-08Clickjacking protection worksOWASP ClickjackingTest embedding page in iframe
Browser validation: Use JavaScript via 
act
to enumerate localStorage keys, check script tags for SRI, list all network requests to external domains. Use 
get_browser_console_logs
to check for leaked data.
检查ID检查内容参考标准方法
CLI-01客户端存储中无敏感数据OWASP Storage检查localStorage、sessionStorage、IndexedDB
CLI-02CDN资源带有Subresource Integrity (SRI)供应链检查外部脚本/样式的
integrity
属性
CLI-03第三方脚本清单供应链列出所有外部脚本源
CLI-04无eval()或结合用户输入的innerHTMLCWE-79扫描JavaScript中的危险模式
CLI-05Service Worker范围受限客户端安全检查SW注册范围
CLI-06WebSocket连接使用WSS传输检查WS连接URL
CLI-07控制台日志中无敏感数据信息泄露检查
get_browser_console_logs
输出
CLI-08点击劫持防护生效OWASP Clickjacking测试将页面嵌入iframe
浏览器验证： 通过
act
执行JavaScript枚举localStorage键，检查脚本标签的SRI，列出所有外部域名的网络请求。使用
get_browser_console_logs
检查泄露的数据。

Category F: Dependency & Supply Chain (DEP)

类别F：依赖项与供应链（DEP）

Check IDCheckStandardMethod
DEP-01No known vulnerable dependenciesOWASP A06 / CWE-1035Run 
npm audit
/ 
pip audit
DEP-02Lock file exists and is committedSupply chainCheck for package-lock.json / yarn.lock / pnpm-lock.yaml
DEP-03No unnecessary dependenciesAttack surfaceCheck for unused packages
DEP-04CDN resources use SRISupply chainCheck integrity attributes (same as CLI-02)
DEP-05No typosquatting risk in dependenciesSupply chainCheck package names against known packages
Validation: Run dependency audit commands. Cross-reference with codebase scan from Phase 2.
检查ID检查内容参考标准方法
DEP-01无已知漏洞的依赖项OWASP A06 / CWE-1035运行
npm audit
/ 
pip audit
DEP-02存在并提交锁文件供应链检查package-lock.json / yarn.lock / pnpm-lock.yaml
DEP-03无不必要的依赖项攻击面检查未使用的包
DEP-04CDN资源使用SRI供应链检查完整性属性（同CLI-02）
DEP-05依赖项无打字 squatting 风险供应链对照已知包检查包名
验证： 运行依赖项审计命令。与第二阶段的代码库扫描结果交叉验证。

Phase 4: Report

第四阶段：报告

Generate a structured report saved to 
shiplight/reports/security-review-{date}.md
:
markdown
undefined
生成结构化报告并保存至
shiplight/reports/security-review-{date}.md
：
markdown
undefined

Security Review Report

安全审查报告

Date: {date} URL: {url} Auth mechanism: {type} Attack surface: {summary}
日期： {date} URL： {url} 认证机制： {type} 攻击面： {summary}

Overall Score: {X}/10 | Confidence: {X}%

总体评分：{X}/10 | 置信度：{X}%

Score Breakdown

评分明细

CategoryScoreFindings
HTTP Headers (HDR)6/101 critical, 2 high
Auth & Sessions (AUTH)4/102 critical, 1 high
Input Validation (INJ)7/101 high, 2 medium
Access Control (AC)8/101 medium
Client-Side (CLI)5/101 critical, 1 high
Dependencies (DEP)9/101 low
类别得分发现问题
HTTP头（HDR）6/101个严重，2个高危
认证与会话（AUTH）4/102个严重，1个高危
输入验证（INJ）7/101个高危，2个中危
访问控制（AC）8/101个中危
客户端（CLI）5/101个严重，1个高危
依赖项（DEP）9/101个低危

Findings

发现问题

CRITICAL

严重级别

AUTH-01: JWT stored in localStorage — XSS leads to full account takeover

AUTH-01: JWT存储在localStorage中 —— XSS可导致完全账户接管

  • Standard: OWASP ASVS 3.3.2 / CWE-922
  • Finding: Access token stored in 
    localStorage
    under key 
    auth_token
    , accessible to any XSS payload
  • Evidence: [screenshot of Application > Storage showing JWT]
  • Attack scenario: Any XSS vulnerability (even via third-party script) can exfiltrate all user tokens
  • CVSS estimate: 8.1 (High)
  • Confidence: 95%
...
undefined
  • 标准： OWASP ASVS 3.3.2 / CWE-922
  • 发现： 访问令牌存储在
    localStorage
    的
    auth_token
    键下，任何XSS载荷均可访问
  • 证据： [Application > Storage中显示JWT的截图]
  • 攻击场景： 任何XSS漏洞（即使来自第三方脚本）均可窃取所有用户令牌
  • CVSS估算： 8.1（高危）
  • 置信度： 95%
...
undefined

Confidence Scoring

置信度评分

  • 90-100%: Exploited and verified in browser (e.g., XSS payload executed, unauthorized access confirmed)
  • 70-89%: Strong evidence from inspection (e.g., missing header confirmed, insecure cookie flags observed)
  • 50-69%: Code-level evidence, not fully validated at runtime
  • Below 50%: Don't report — too speculative
  • 90-100%：在浏览器中利用并验证（如XSS载荷执行、未授权访问确认）
  • 70-89%：检查发现确凿证据（如确认缺失头、观察到不安全的Cookie标志）
  • 50-69%：代码层面证据，未在运行时完全验证
  • 低于50%：不报告——过于推测

Phase 5: Remediate

第五阶段：修复

For each finding, provide:
针对每项发现，提供：

1. Fix guidance

1. 修复指南

markdown
undefined
markdown
undefined

AUTH-01: JWT stored in localStorage

AUTH-01: JWT存储在localStorage中

Risk: Any XSS → full account takeover File: src/lib/auth.ts:47 Current: 
localStorage.setItem('auth_token', jwt)
Fix: Move to HttpOnly cookie set by the server
  • Server: 
    Set-Cookie: token=<jwt>; HttpOnly; Secure; SameSite=Strict; Path=/
  • Client: Remove all localStorage token operations
  • API calls: Cookies sent automatically (remove Authorization header) Migration steps:
  1. Add cookie-setting endpoint on server
  2. Update API middleware to read from cookie
  3. Remove client-side token storage
  4. Update CORS to allow credentials
undefined
风险： 任何XSS漏洞均可导致完全账户接管 文件： src/lib/auth.ts:47 当前代码： 
localStorage.setItem('auth_token', jwt)
修复方案： 迁移至服务器设置的HttpOnly Cookie
  • 服务器：
    Set-Cookie: token=<jwt>; HttpOnly; Secure; SameSite=Strict; Path=/
  • 客户端：移除所有localStorage令牌操作
  • API调用：自动发送Cookie（移除Authorization头） 迁移步骤：
  1. 在服务器添加设置Cookie的端点
  2. 更新API中间件以从Cookie读取令牌
  3. 移除客户端令牌存储逻辑
  4. 更新CORS以允许凭证
undefined

2. YAML regression test

2. YAML回归测试

yaml
- name: auth-01-no-tokens-in-localstorage
  description: Verify authentication tokens are not stored in localStorage
  severity: critical
  standard: OWASP-ASVS-3.3.2
  steps:
    - URL: /login
    - intent: Enter test username
      action: fill
      locator: "getByLabel('Email')"
      value: "test@example.com"
    - intent: Enter test password
      action: fill
      locator: "getByLabel('Password')"
      value: "testpass123"
    - intent: Click login button
      action: click
      locator: "getByRole('button', { name: 'Sign in' })"
    - WAIT_UNTIL: User is logged in and dashboard is visible
      timeout_seconds: 15
    - CODE: |
        const keys = Object.keys(localStorage);
        const tokenKeys = keys.filter(k =>
          /token|jwt|auth|session|access/i.test(k)
        );
        if (tokenKeys.length > 0) {
          throw new Error(
            `Auth tokens found in localStorage: ${tokenKeys.join(', ')}`
          );
        }
    - VERIFY: No authentication tokens are stored in browser localStorage
Save all YAML tests to 
shiplight/tests/security-review.test.yaml
.
yaml
- name: auth-01-no-tokens-in-localstorage
  description: Verify authentication tokens are not stored in localStorage
  severity: critical
  standard: OWASP-ASVS-3.3.2
  steps:
    - URL: /login
    - intent: Enter test username
      action: fill
      locator: "getByLabel('Email')"
      value: "test@example.com"
    - intent: Enter test password
      action: fill
      locator: "getByLabel('Password')"
      value: "testpass123"
    - intent: Click login button
      action: click
      locator: "getByRole('button', { name: 'Sign in' })"
    - WAIT_UNTIL: User is logged in and dashboard is visible
      timeout_seconds: 15
    - CODE: |
        const keys = Object.keys(localStorage);
        const tokenKeys = keys.filter(k =>
          /token|jwt|auth|session|access/i.test(k)
        );
        if (tokenKeys.length > 0) {
          throw new Error(
            `Auth tokens found in localStorage: ${tokenKeys.join(', ')}`
          );
        }
    - VERIFY: No authentication tokens are stored in browser localStorage
将所有YAML测试保存至
shiplight/tests/security-review.test.yaml
。

Penetration Test Depth Levels

渗透测试深度级别

  • --quick
    : Headers (HDR) + Cookie flags (AUTH-02/03/04) + localStorage check (AUTH-01) + dependency audit (DEP-01). ~2 minutes.
  • default: All categories, standard payloads. ~10 minutes.
  • --thorough
    : All categories + extended injection payloads + IDOR enumeration + brute force testing + full third-party script analysis. ~20-30 minutes.
  • --quick
    ：头检查（HDR） + Cookie标志（AUTH-02/03/04） + localStorage检查（AUTH-01） + 依赖项审计（DEP-01）。约2分钟。
  • 默认：所有类别，标准载荷。约10分钟。
  • --thorough
    ：所有类别 + 扩展注入载荷 + IDOR枚举 + 暴力破解测试 + 完整第三方脚本分析。约20-30分钟。

Tips

提示

  • Always use test credentials, never production credentials
  • XSS test payloads are non-destructive (
    alert(1)
    ) — safe for staging environments
  • For authenticated testing, save the session with 
    save_storage_state
    after login
  • Run 
    npm audit
    before the browser-based review to catch known CVEs early
  • Use 
    get_browser_console_logs
    — many security issues produce console warnings
  • Close the session with 
    close_session
    and use 
    generate_html_report
    for evidence
  • 始终使用测试凭证，切勿使用生产凭证
  • XSS测试载荷为非破坏性（
    alert(1)
    ）——在预发布环境中安全使用
  • 对于已认证测试，登录后使用
    save_storage_state
    保存会话
  • 在基于浏览器的审查前运行
    npm audit
    ，尽早发现已知CVE
  • 使用
    get_browser_console_logs
    ——许多安全问题会产生控制台警告
  • 使用
    close_session
    关闭会话，并使用
    generate_html_report
    生成证据报告