vulns.co
/
GKData.io MCP
AP / Application

JavaScript and client trust

Review browser code as an untrusted-data consumer: preserve origin, context, serialization, and server-authorization boundaries.

Guide 06 / 154 review notesUpdated 2026-10-11
Download .md ↓JSON ↗

The review

What to look for

Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.

  1. Map data contexts

    Identify where server data, URLs, messages, and generated content enter HTML, script, navigation, or framework rendering contexts.

  2. Review message authority

    Require an explicit sender origin, message shape, and allowed action before a listener changes state or reveals data.

  3. Check serialization

    Ensure data remains data across server rendering, hydration, logs, and client components.

  4. Keep authorization server-side

    Confirm browser controls do not substitute for a server decision about protected resources.

What to produce

  • Source-to-context map
  • Message contract review
  • Rendering control notes

Common mistakes

  • Treating client checks as access control
  • Using generic sanitization without knowing the output context
  • Trusting all same-window messages

Continue the study

Reading & source context

Editorial notes above connect these references. Open each record for its original source and review date.

HTML5 Security Cheat Sheet: Web MessagingOWASP Cheat Sheet Series Next.js data security: server authorization and client-visible dataNext.js / Vercel Trusted Types: typed sinks depend on trustworthy policy creationWorld Wide Web Consortium

Visual models

An incoming browser message first passes origin, sender-context and format validation. A separate decision checks the operation and recipient. Failed checks reject the message without disclosure or state change. Approved content remains data and only the permitted action is performed.Browser messages need separate trust checks ↗A request enters a server-side caller, resource and operation authorization decision. Denial returns no protected data. Approval proceeds to explicit field selection before serialization. Only permitted, necessary fields cross into client-visible data. A separate consumer-context handling step keeps content, including generated text, from acquiring executable meaning before display. Browser rendering never supplies server authorization.Server disclosure and browser interpretation ↗

Connected disclosures

Facebook SDK message authentication relied on insecure randomnessMeta Meta Pixel cross-window handling lost message and token authorityMeta Framework serialization change exposed private HackerOne user attributesHackerOne

From the field toolkit

Advanced JavaScript Analysisplaybooks ↗SPA / Next.js / React Huntingplaybooks ↗postMessage & DOM gadgetsplaybooks ↗JavaScript reviewchecklists ↗jsluicetools ↗xnLinkFindertools ↗sourcemappertools ↗

Guide by GK Data · Research snapshot 2026-10-04.
Sources and review dates are preserved in the library provenance.

Next skillCache deception and cache poisoning →