UI Secure Review
Use this skill when the user asks for a frontend review with a security-first lens.
When to use
- Reviewing PRs that touch UI rendering, routing, auth, storage, or API calls.
- Auditing React, Vue, or plain JavaScript UI code for exploitable patterns.
- Hardening existing UI code before release.
When not to use
- Pure visual polish work with no logic or data handling changes.
- Backend-only or infra-only changes.
Review workflow
- Map changed files and rank risk by feature type.
- Run quick pattern scans for dangerous APIs and sinks.
- Read high-risk files in detail and trace data from input to render.
- Confirm exploitability, impact, and realistic attack path.
- Report findings ordered by severity with exact file and line references.
- Suggest minimum safe fix and regression tests for each finding.
High-risk patterns to check
- HTML injection:
dangerouslySetInnerHTML, v-html, innerHTML, outerHTML.
- Script execution:
eval, new Function, string-based timers.
- URL and navigation sinks: dynamic
href, window.open, router redirects from untrusted params.
- Tabnabbing risk: external links with
target="_blank" missing rel="noopener noreferrer".
- Token exposure: auth tokens in query params, logs, localStorage, or error traces.
- Cross-origin trust:
postMessage without strict origin and source checks.
- Client-only authorization assumptions that can be bypassed in browser devtools.
- Sensitive data persistence in cache, URL, or browser storage.
Quick scan commands
Use these patterns as a first pass, then manually verify context.
rg -n "dangerouslySetInnerHTML|v-html|innerHTML|outerHTML|eval\(|new Function\(" frontend/src
rg -n "window\.open|postMessage|target=\"_blank\"|localStorage|sessionStorage" frontend/src
rg -n "token|authorization|auth|redirect|location\.href|router\.push" frontend/src
Fix guidance
- Prefer safe templating and escaped rendering over raw HTML insertion.
- Validate and normalize all dynamic URLs before navigation.
- Keep tokens in secure httpOnly cookies when architecture allows.
- Add strict allowlists for cross-origin messaging and navigation targets.
- Enforce authorization on the server even if UI hides actions.
Output contract
- Findings first, ordered by severity.
- Include file path, line, risk, exploit scenario, and concrete fix.
- Explicitly say "No high-confidence findings" if nothing actionable is found.
- Mention residual test gaps or assumptions.
1---2name: ui-secure-review3description: Review frontend and UI changes for concrete security risks such as XSS, unsafe URL handling, token leakage, missing origin checks, and client-side authorization gaps. Use when users ask for a UI code review focused on safety and reliability.4---56# UI Secure Review78Use this skill when the user asks for a frontend review with a security-first lens.910## When to use11- Reviewing PRs that touch UI rendering, routing, auth, storage, or API calls.12- Auditing React, Vue, or plain JavaScript UI code for exploitable patterns.13- Hardening existing UI code before release.1415## When not to use16- Pure visual polish work with no logic or data handling changes.17- Backend-only or infra-only changes.1819## Review workflow201. Map changed files and rank risk by feature type.212. Run quick pattern scans for dangerous APIs and sinks.223. Read high-risk files in detail and trace data from input to render.234. Confirm exploitability, impact, and realistic attack path.245. Report findings ordered by severity with exact file and line references.256. Suggest minimum safe fix and regression tests for each finding.2627## High-risk patterns to check28- HTML injection: `dangerouslySetInnerHTML`, `v-html`, `innerHTML`, `outerHTML`.29- Script execution: `eval`, `new Function`, string-based timers.30- URL and navigation sinks: dynamic `href`, `window.open`, router redirects from untrusted params.31- Tabnabbing risk: external links with `target="_blank"` missing `rel="noopener noreferrer"`.32- Token exposure: auth tokens in query params, logs, localStorage, or error traces.33- Cross-origin trust: `postMessage` without strict `origin` and `source` checks.34- Client-only authorization assumptions that can be bypassed in browser devtools.35- Sensitive data persistence in cache, URL, or browser storage.3637## Quick scan commands38Use these patterns as a first pass, then manually verify context.3940```bash41rg -n "dangerouslySetInnerHTML|v-html|innerHTML|outerHTML|eval\(|new Function\(" frontend/src42rg -n "window\.open|postMessage|target=\"_blank\"|localStorage|sessionStorage" frontend/src43rg -n "token|authorization|auth|redirect|location\.href|router\.push" frontend/src44```4546## Fix guidance47- Prefer safe templating and escaped rendering over raw HTML insertion.48- Validate and normalize all dynamic URLs before navigation.49- Keep tokens in secure httpOnly cookies when architecture allows.50- Add strict allowlists for cross-origin messaging and navigation targets.51- Enforce authorization on the server even if UI hides actions.5253## Output contract54- Findings first, ordered by severity.55- Include file path, line, risk, exploit scenario, and concrete fix.56- Explicitly say "No high-confidence findings" if nothing actionable is found.57- Mention residual test gaps or assumptions.
lazyagi