Category
Next.js × Supabase アプリ層セキュリティ（脆弱性の検出・多層防御・RLS/認可の検証）実装ガイド
アプリ層セキュリティは『自動化できる水平統制』と『設計でしか守れない垂直リスク』に分かれます。前者——セキュリティヘッダー/CSP、サーバーレスで正しく効くレート制限、CSRF/Origin検証、型付きenv境界、SQLi/SSRF/XSS等の注入——はツールで網羅的に検出・強化できます。後者——認可/IDOR・Supabase RLSの設計の正しさ・テナント分離・業務ロジック——は検出・警告はできても、修正は人間の設計判断に委ねられます。本クラスタは、無料OSS『Aegis』のscan(SAST)・RLS検証・probe(DAST)・CI(SARIF)を軸に、競合が見落とすSupabase RLSの設定ミス検出を中核に据え、何が自動で守れて、何が監査・設計を要するのかを正直に切り分けます。経済産業大臣賞のB2B SaaS、本番二重課金0件の決済基盤の知見を根拠に、速く・安く・安全に作るための判断材料を提供します。
22 articles in total
Foundational guide
Foundational guide (start here)
Next.js × Supabase Application Security Complete Guide — Protecting Authorization and RLS with Vulnerability Detection and Defense in Depth
The overall picture of security for AI-mass-produced Next.js × Supabase apps. We divide it into automatable horizontal controls (CSP, rate limiting, CSRF, Zod validation), injection detected by static analysis (SQLi/SSRF/XSS), and vertical risks only design can close (authorization/IDOR, RLS, tenant isolation), and systematize how to protect with 3 detection layers and defense in depth.
Related practical articles
- セキュリティ脆弱性診断AI駆動開発OWASP
Vulnerability assessment of AI-generated code (vibe coding) [2026 edition] — a practical procedure to crush, before release, the vulnerabilities that generative AI multiplies
Why does code written by generative AI (Copilot/Claude, etc.) have more vulnerabilities? Drawing on research data from Stanford and NYU and 'slopsquatting,' it explains the risks specific to AI-generated code and a practical procedure to crush them in four layers (SCA/secrets/SAST/DAST) before release, with real code. It also shows the safety AI cannot in principle create (authorization, business logic) and the design of human verification gates.
9 min read - Next.jsセキュリティTypeScriptアーキテクチャ設計
CSRF / Origin protection for Next.js Server Actions — what's protected by default, and what you should add
Next.js App Router's Server Actions have a degree of CSRF resistance via POST-only + Origin/Host match check + encrypted action IDs. But it's not enough. It honestly explains Origin verification, SameSite cookies, and Route Handler protection — what's automatically protected and what to add — faithful to the scope the official docs show.
21 min read - Next.jsTypeScriptセキュリティアーキテクチャ設計
Next.js Environment Variables and Secret-Leak Countermeasures — The NEXT_PUBLIC_ Trap, and the Typed env Boundary
Environment variables with the NEXT_PUBLIC_ prefix are baked into the client bundle at build time and published. We systematically explain — in Next.js vulnerable→fixed real code — the server-only boundary that prevents secret-key mixing accidents, typed env validation with Zod, and secret-scan implementation.
24 min read - Next.jsセキュリティTypeScript
Next.js open-redirect prevention — verify the auth callbackUrl / redirect()
Passing user input straight to redirect() or callbackUrl lets a trusted own domain be the starting point to lure to an attacker site, leading to phishing or token theft right after authentication. It explains how to fall to the safe side with relative-path enforcement, a host allowlist, and verification with new URL, with vulnerable→fixed code of Next.js's auth flow, and bypass countermeasures like //evil and backslash.
19 min read - Next.jsセキュリティアーキテクチャ設計TypeScript
Next.js security headers and CSP (nonce) — automate defense-in-depth with one middleware
How to introduce security headers like CSP, HSTS, X-Content-Type-Options, Referrer-Policy, and frame-ancestors all at once with one Next.js App Router middleware. It explains in real code why a hand-written nonce-style CSP breaks and how to automate it, and honestly shows the limit that CSP is a complement to XSS countermeasures, not a substitute for output design.
20 min read - Next.jsアーキテクチャ設計セキュリティTypeScript
Rate Limiting That 'Actually Works' in Next.js — Why In-Memory Breaks in Serverless, and Distributed-Store Design
Because Vercel/Lambda instances are disposable and run concurrently, in-process-memory rate limiting passes straight through. We explain — in real Next.js code (middleware/route handler) — a design that implements an atomic sliding window with a distributed store like Upstash Redis.
23 min read - Next.jsセキュリティTypeScriptアーキテクチャ設計
Next.js SSRF prevention — making the fetch of Server Actions / Route Handlers safe (detect with taint analysis)
When the server fetches a user-input URL, SSRF can reach cloud metadata (169.254.169.254) or internal services. It explains, with vulnerable→fixed code of the Next.js App Router, a scheme/host allowlist, blocking private IPs, prohibiting redirect-following, and taint detection of tainted-input→fetch-sink.
20 min read - セキュリティSupabaseNext.jsアーキテクチャ設計B2B SaaS
What Does a Security Audit Actually Look At — Where Automation Is Enough, and Where an Audit Is Required (Next.js × Supabase)
An honest explanation of what a security audit for a Next.js × Supabase app actually inspects. We map out the boundary between the 'horizontal controls' that automated tools (SAST/DAST/SCA) can close and the 'vertical risks' that only an audit can close (authorization/IDOR, RLS design, tenant isolation, business logic), when an audit becomes necessary, and the 3-stage approach with pricing (from ¥98,000).
28 min read - Next.jsセキュリティアーキテクチャ設計TypeScript
Stop security in CI — the design of GitHub Actions, SARIF, and 'block only the high-confidence'
A design that incorporates security inspection into CI and stops the build only on high-confidence detections. It explains, with actual YAML and commands, running SAST in GitHub Actions, code-scanning integration via SARIF, and operation that doesn't break CI with false positives (block only the confirmed via static×dynamic correlation).
21 min read - Next.jsReactセキュリティTypeScript
XSS / DOM-XSS prevention in Next.js / React — the holes of dangerouslySetInnerHTML, and safe sanitization / CSP
React escapes JSX by default, but it slips out via dangerouslySetInnerHTML, href=javascript:, DOM manipulation through ref, and DOM sinks. It explains, with vulnerable→fixed real code, where XSS/DOM-XSS occurs, output-time sanitization with DOMPurify, and the defense-in-depth of CSP (nonce) / Trusted Types.
17 min read - SupabaseRLSNext.jsセキュリティTypeScript
Correctly Handling the anon Key and service_role Key — The Key You May Publish, the Key That Means Instant Death if Exposed, and the RLS-Bypass Boundary
Supabase's anon key is meant to be public, but the major premise is that RLS is taking effect. The service_role key completely ignores RLS with the BYPASSRLS privilege, and if leaked, all data is exposed. We explain the design of key placement, the server boundary, and ownership checks in real Next.js App Router code.
22 min read - SupabaseRLSB2B SaaSセキュリティアーキテクチャ設計
Verifying Cross-Tenant Leaks — How to 'Prove' Supabase RLS Isolation (Don't End at Design Alone)
Explains how to prove, by verification, that 'isolation isn't broken' for the cross-tenant leak where another tenant's data is visible in a multi-tenant SaaS — not just designing RLS. Shows the practice of raising confidence with pgTAP-style regression tests, ownership checks, safe dynamic probing (DAST), and SAST correlation, with vulnerable→verified real code.
23 min read - SupabasePostgreSQLセキュリティTypeScript
SQL-injection prevention for Supabase / PostgreSQL — the traps of rpc, raw SQL, and dynamic SQL inside functions
Supabase makes plain SQL injection unlikely with PostgREST and parameterized queries. But dynamic SQL inside functions (EXECUTE and string concatenation), misuse of format()'s %s, raw SQL, and the assembly of search filters become injection routes. This explains, with vulnerable→fixed real SQL/TS, how to make it safe with EXECUTE USING parameterization, format()'s %I/%L, quote_ident/literal, and allowlist verification.
19 min read - SupabaseRLSPostgreSQLセキュリティアーキテクチャ設計
Detecting Supabase RLS Misconfigurations — Surfacing Not-Enabled, Missing WITH CHECK, USING(true), and Over-Granted anon from Your Migrations
Supabase RLS opens holes by 'thinking you enabled it.' A practical guide to surfacing and plugging the dangerous patterns — RLS not enabled, missing WITH CHECK, USING(true), over-granted anon, and SECURITY DEFINER without a fixed search_path — with static verification of supabase/migrations/**.sql.
25 min read - SupabaseRLSセキュリティPostgreSQLNext.js
Supabase RLSセキュリティ実態調査 — 公開アプリ1,000件中9.2%が『認証はするが認可しない』
公開GitHubのSupabaseアプリ1,000件・116,662件のRLSポリシを静的スキャンした一次調査。RLSを持つ994件の9.2%が『認証はするが行を所有者に絞らない』ポリシを持っていた（下限値）。看板ルールはこの2倍規模でも precision 1.0 を維持し、走査自体が姉妹ルールの誤検知を炙り出して0に。auth.role()='authenticated'の落とし穴と自分のアプリの測り方まで、実データで解説します。
18 min read - SupabaseRLSPostgreSQLセキュリティ
The 'write bypass' caused by a missing WITH CHECK in Supabase RLS — the difference from USING, and correctly protecting INSERT/UPDATE
Organizing the easily-confused difference between USING (the read filter) and WITH CHECK (the write filter) in Supabase RLS, this explains, with vulnerable→fixed SQL for INSERT/UPDATE/ALL, the 'write bypass' where a write policy lacking WITH CHECK lets an authenticated user create rows with someone else's user_id or another tenant's id.
21 min read - SupabasePostgreSQLRLSセキュリティ
The pitfall of Supabase's SECURITY DEFINER functions — an unfixed search_path produces RLS bypass and privilege escalation
Because a SECURITY DEFINER function runs with the definer's privileges, if you don't fix the search_path an attacker can inject a same-named object into a temporary schema or public, bypass RLS, and escalate privileges. This article explains the safe way to write them — set search_path = '', schema-qualify, and minimize GRANT — and how to detect the flaw in migrations/pg_proc, with real SQL.
20 min read - セキュリティ脆弱性診断B2B SaaSコスト最適化
The cost and market rate of web-app vulnerability assessment [2026 edition] — price bands by method, how to read estimates, how to choose without failing
An honest explanation, from the buyer's perspective, of the cost and market rate of web-app vulnerability assessment. Price bands by method (automated / manual / hybrid / penetration), guides by target (web, API, mobile, platform), the seven cost drivers that move an estimate, the trap of 'all-inclusive' estimates, the legitimate way to keep it cheap, and how to spot an assessment that's too cheap — summarized together with my own transparent pricing.
10 min read - セキュリティ脆弱性診断OWASPNext.jsDevSecOps
How to Do Web-App Vulnerability Assessment [2026 Edition] — A Practical Guide to Automating with the OWASP Official Methods (Top 10:2025 / WSTG / ASVS) and ZAP・SAST
A hands-on for practicing web-app vulnerability assessment from 'the range you can do yourself.' Faithful to the official methods of OWASP Top 10:2025・WSTG v4.2・ASVS 5.0, it explains SCA・SAST(Semgrep)・secret scanning・DAST(ZAP)・CI/SARIF integration with real code, and honestly shows the limits of automation (authorization/IDOR・business logic) and the boundary where a professional audit is needed.
23 min read - セキュリティ脆弱性診断OWASPDevSecOps
Web-app vulnerability-scanner comparison [2026 edition] — how to choose among OWASP ZAP / Burp Suite / Semgrep / commercial & Japanese SaaS
A comparison guide for correctly choosing web-app vulnerability-scanning tools by type (SAST/DAST/SCA/secrets) and role. The difference between free ZAP (Apache-2.0) and the $475/year Burp Suite Professional, SAST like Semgrep, dependency assessment with npm audit/Dependabot, Japanese SaaS-type tools (AeyeScan/VAddy/Securify), and commercial integrated DAST — with a selection flow by scale/budget/setup, and honestly showing the area tools can't close.
9 min read - SupabaseRLSNext.jsセキュリティTypeScript
This is how the 'you can see other people's data' IDOR vulnerability is born in Supabase — a practical guide to finding and fixing the authorization flaws lurking in AI-generated Next.js code
Explains how AI-mass-produced Next.js × Supabase apps expose other people's data via OWASP API1:2023 BOLA (IDOR), centered on CVE-2025-48757 and RLS bypass by the service_role key. It shows, with vulnerable→fixed real code, why a WAF or security headers can't prevent it, and how to systematically find and fix it with three layers: taint analysis, RLS verification, and runtime confirmation.
18 min read