用途：在已获得目标认证访问、能读取自己数据的前提下，测试是否能越权修改数据。这是 Supabase 类 SaaS 的常见模式，也见于 Firebase、自定义 REST API 和 GraphQL 后端。核心模式是：GET /resource 只返回自己的数据（RLS/鉴权正常），但 PATCH /resource 可修改层级、角色、余额、订阅状态等。
主要能力：分三阶段。阶段一识别可写端点，对 users、subscribers、profiles、accounts、settings 等端点用 PATCH/PUT/POST 探测，200/400 表示端点存在且接受写入，404 表示不存在，405 表示方法不对。阶段二测试写入操作，尝试修改特权字段，如 tier_id、subscribed、amount、full_name、avatar_url、document_analysis_limit 等。阶段三测试跨用户写入（IDOR 写），用 user_id=neq.${MY_USER_ID} 等过滤条件尝试修改他人数据，返回空数组表示 RLS 阻止，返回数据则表示存在严重缺口。
使用方式：设置 TARGET 和 TOKEN 环境变量，用 curl 携带 Authorization: Bearer 头与 Content-Type: application/json 发起请求。示例命令保留原样，如 curl --max-time 30 --connect-timeout 10 -sk -X PATCH "${TARGET}/subscribers?user_id=eq.${USER_ID}" -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" -d '{"tier_id":"<PRO_TIER_ID>","subscribed":true}'。
验证：确认写入缺口需 PATCH/POST 返回 200 且响应体含被修改数据，再用 GET 同一资源复核。受保护时返回 401/403 或静默丢弃未授权字段。假阳性是端点接受请求但未真正持久化，需用 GET 验证。
适用场景：Supabase 后端 SaaS、Firebase、自定义 REST API、GraphQL 后端的越权写入测试。
限制与注意：写入原语本身不等于可利用，需证明写入能达成什么；原子写入可能无竞态窗口；文件写入需能执行；内存破坏写入需可控且影响可预测。仅限授权测试使用。