Last audited: 2026-02-14 (vulnerability table below may be stale — re-run cd frontend && npm audit --omit=dev to refresh)

Note: The project upgraded to Next.js 16.2.6. The advisories below were originally filed against Next.js 14.x. Run npm audit --omit=dev to verify which, if any, still apply to the current version.

GHSA-9g9p-9gw9-jx7f — Image Optimizer DoS:

• Affects self-hosted Next.js with remotePatterns in image config.
• We deploy on Vercel (managed infrastructure), not self-hosted.
• Our next.config.js does not configure remotePatterns.
• Not practically exploitable in this deployment.

GHSA-h25m-26qc-wcjf — RSC deserialization DoS:

• Requires "insecure React Server Components" usage patterns.
• Our RSC usage is standard (data fetching via Supabase client).
• Vercel's infrastructure provides additional request-level protections.
• Low practical risk. Resolved — project is now on Next.js 16.

GHSA-5j98-mcp5-4vw2 — glob CLI injection:

• The glob CLI (--cmd flag) allows command injection.
• This is a dev/build-time dependency (via eslint-config-next).
• Never exposed to user input at runtime.
• Not exploitable — only runs during development/CI builds with trusted input.

The project is now on Next.js 16.2.6. The advisories listed above were filed against v14.x and may no longer apply. Re-run npm audit --omit=dev and refresh this table when vulnerabilities change.

• Row Level Security (RLS): All Supabase tables have RLS enabled.
• SECURITY DEFINER functions: All 10 API RPCs use SECURITY DEFINER with anon_can_execute = false.
• Auth middleware: All /app/* routes require authenticated sessions.
• Open redirect prevention: Login redirect param validated (relative paths only, no // prefix).
• No hardcoded secrets: All credentials via environment variables.

This is a public repository by design. Source visibility is expected.

• Code license: AGPL-3.0 in LICENSE.
• Data license: CC BY-NC-SA 4.0 in DATA_LICENSE.md.
• Operational security model: Secrets are never committed; production secrets are managed via environment variables and CI/provider secret stores.
• Abuse resistance: RLS + RPC-only data access + rate limits and query guardrails.

• Schema, migrations, and implementation details are intentionally visible.
• Competitive protection comes from licensing terms and operational execution, not code secrecy.
• Any accidental secret disclosure must be treated as an incident: rotate keys, purge from history, and document remediation.

TryVit is a public food health scoring platform — there is no user-generated content, no PII, and no authentication-gated data. The primary security concerns are:

┌─────────────────────────────────────────────────────┐
│  PostgREST  (runs as `authenticator` → sets `anon`) │
├─────────────────────────────────────────────────────┤
│                                                     │
│  anon + authenticated (shared)                      │
│    ✓ EXECUTE api_product_detail(bigint)              │
│    ✓ EXECUTE api_search_products(text, ...)          │
│    ✓ EXECUTE api_category_listing(text, ...)         │
│    ✓ EXECUTE api_product_detail_by_ean(text, ...)    │
│    ✓ EXECUTE api_score_explanation(bigint)           │
│    ✓ EXECUTE api_better_alternatives(bigint, ...)    │
│    ✓ EXECUTE api_data_confidence(bigint)             │
│    ✗ SELECT on any table or view                     │
│    ✗ INSERT / UPDATE / DELETE on data tables         │
│    ✗ EXECUTE on internal functions                   │
│                                                     │
│  authenticated only                                 │
│    ✓ EXECUTE api_get_user_preferences()              │
│    ✓ EXECUTE api_set_user_preferences(...)           │
│    ✓ INSERT/UPDATE own row in user_preferences       │
│      (RLS: auth.uid() = user_id)                    │
│                                                     │
│  service_role                                       │
│    ✓ Full CRUD on all tables                        │
│    ✓ Used by data pipelines and admin scripts        │
│                                                     │
├─────────────────────────────────────────────────────┤
│  SECURITY DEFINER functions (run as `postgres`)     │
│    → Can read all tables/views regardless of        │
│      client-role privileges                         │
│    → All have `SET search_path = public`            │
│      (prevents search_path hijacking)               │
│    → Note: `postgres` is NOT superuser in Supabase  │
│      (rolsuper=false) — relies on explicit grants   │
└─────────────────────────────────────────────────────┘

Direct REST access to tables and views is blocked for client-facing roles (anon, authenticated). All data access is routed through nine curated API functions:

This approach provides:

• Contract stability — API key sets and country-echo contract are locked and tested (33 API contract QA checks)
• Performance control — Functions apply pagination limits and optimized queries
• Security — No direct table access means zero risk of filter bypass or column enumeration

RLS is enabled and forced on all 12 data tables.

Public data tables (11 tables): Policies are SELECT USING (true) — permissive by design since all data is public. These policies serve as defense-in-depth: even if SELECT privilege were accidentally re-granted, RLS would still apply. Write policies (INSERT/UPDATE/DELETE) do not exist, enforcing read-only access.

user_preferences (1 table): User-scoped RLS with auth.uid() = user_id on all operations (SELECT, INSERT, UPDATE, DELETE). Each authenticated user can only access their own row. This is the only table with user-specific write policies.

resolve_effective_country(text) is a SECURITY DEFINER internal helper with SET search_path = public. EXECUTE is revoked from PUBLIC, anon, and authenticated — it can only be called by other SECURITY DEFINER functions (the API layer). This function reads user_preferences to resolve the user's preferred country, and the SECURITY DEFINER attribute ensures this works regardless of the caller's role privileges.

Security posture is validated by the automated security QA suite (QA__security_posture.sql):

1. All data tables have RLS enabled
2. All data tables have FORCE RLS enabled
3. Each data table has a SELECT policy
4. No write policies exist on public data tables (user_preferences excluded)
5. anon has no INSERT privilege
6. anon has no UPDATE privilege
7. anon has no DELETE privilege
8. All api_* functions are SECURITY DEFINER
9. anon can EXECUTE all api_* functions
10. anon blocked from internal functions (incl. resolve_effective_country)
11. service_role retains full privileges
12. All api_* functions have search_path set
13. anon has no SELECT on data tables (RPC-only)
14. New tables have RLS enabled
15. Products table has updated_at trigger
16. user_preferences has RLS enabled and forced
17. user_preferences has user-scoped SELECT policy
18. user_preferences has user-scoped INSERT policy
19. user_preferences has user-scoped UPDATE policy
20. user_preferences has updated_at trigger
21. resolve_effective_country is SECURITY DEFINER with search_path set
22. resolve_effective_country EXECUTE revoked from authenticated

Total QA coverage: 776 checks across 49 suites + 20 negative validation tests.