| name | pci-payment-ui-security-review |
| description | Statically review payment-page frontend code for PCI-DSS-relevant defects in the browser/DOM slice only — raw PAN collection in self-controlled inputs instead of Stripe hosted fields, card data persisted client-side or to analytics, raw card data POSTed to a first-party endpoint, and third-party scripts loaded without Subresource Integrity — grounded in Stripe's own tokenization docs and PCI-DSS v4 script-security requirements. |
| allowed-tools | Read Grep Glob |
| metadata | {"author":"github: Raishin","version":"0.1.0","updated":"2026-07-03","category":"security"} |
PCI Payment UI Security Review
Purpose
Review payment-collection frontend code — checkout pages, card-entry forms, and any script loaded on a page that collects cardholder data — for the frontend-specific defect classes that keep raw cardholder data out of the DOM and out of merchant-controlled JavaScript: raw PAN/CVV collection in a self-controlled <input> instead of Stripe's iframe-isolated hosted fields, card data persistence to localStorage/sessionStorage/analytics/logs, raw card data POSTed to a first-party endpoint instead of tokenized first, and third-party scripts loaded on the payment page without Subresource Integrity (SRI). This skill exists so the review stays anchored to the frontend tokenization boundary and script-integrity surface instead of drifting into a general "payments code review."
When to use
Use this skill when the user asks to:
- review a checkout page or card-entry form for PCI-relevant frontend risk,
- assess whether card-number, expiry, or CVV fields are collected safely (hosted fields vs. raw
<input>),
- audit which scripts load on a payment-collection page and whether they carry Subresource Integrity,
- assess SAQ-A scope reduction claims for a page that outsources card collection to Stripe Elements/Payment Element,
- perform a pre-launch frontend security review of a Stripe-based payment integration.
Do not use this skill for:
- a full PCI-DSS compliance audit — this skill covers only the frontend slice (client-side script inventory/integrity, hosted-field isolation, tokenization boundary). Server-side cardholder-data-environment (CDE) segmentation, network firewalling, key management, encryption-at-rest, access control, and the remaining PCI-DSS requirement families are out of scope; route those to a dedicated infrastructure/compliance review,
- a non-payment page with no card-data collection or third-party script surface — general frontend security review is a different scope,
- a bug that requires live traffic capture (a proxy/network trace confirming what actually left the browser) to confirm exploitation — static analysis proves the structural risk (the code path that would expose or persist raw PAN/CVV), not that raw card data has already left the browser in production.
Context7 Documentation Protocol
- Resolve the Stripe library ID with
resolve-library-id before citing any Stripe Elements/Payment Element or tokenization-mechanism claim; use query-docs to corroborate the specific API behavior (e.g., stripe.createToken(cardElement), stripe.confirmPayment(), stripe.confirmCardPayment()) rather than relying on memory.
- Label every Stripe-API behavioral claim
documentation-based (or repo evidence if confirmed directly against fetched Context7 doc content) — do not assert current Stripe API shape from training memory alone.
- Label every PCI-DSS requirement claim (6.4.3, 11.6.1, or the general SAQ-A scope-reduction rationale)
standard-based — this skill does not verify a merchant's actual PCI compliance status or attestation; it evaluates whether the frontend code matches the documented pattern the standard and Stripe's architecture rely on.
- If Context7 is unavailable, fall back to the
official_docs URLs in this skill's metadata.json and label the claim documentation-based, unverified against current release.
- Read
package.json/script tags first to confirm which Stripe integration is in use (@stripe/stripe-js + Elements, Payment Element, or a legacy/custom integration) — the safe idiom and API names differ; do not assume Elements is in use without confirming.
Lean operating rules
- Raw PAN/CVV collection outside an iframe-isolated hosted field, and any client-side persistence of raw cardholder data, default to HIGH severity. This is a security-scoped skill: do not downgrade a raw-PAN-in-DOM finding to MEDIUM because "it's only in a dev/staging build" — the structural pattern is the risk, not its current deployment target.
- Trace every finding to a concrete file:line and a concrete data-flow path. A finding that says "this form might expose card data" without showing the specific
<input> element, the specific .value read, or the specific POST body construction is not a valid finding — it is a guess.
- Do not flag
<CardNumberElement />, <CardExpiryElement />, <CardCVCElement />, or <PaymentElement /> usage as a defect — these are Stripe's iframe-rendered hosted fields; the PAN/CVV they collect stays inside iframes controlled by Stripe and is never accessible to merchant JavaScript. Only a self-controlled <input> (e.g., <input type="text" id="cardnumber" />) that application JS reads via .value is the raw-pan-input defect.
- Treat any
localStorage, sessionStorage, in-memory app store, or analytics/logging call that could carry a PAN, CVV, or full cardholder data payload as a HIGH finding regardless of whether the value is currently populated in the traced code path — check the shape of the object being persisted, not just its current runtime value.
- Treat a first-party POST (
fetch/XMLHttpRequest/form submit to a first-party endpoint) carrying raw card fields (PAN, CVV, expiry) as a HIGH finding. The safe pattern tokenizes first via the Stripe API (stripe.createToken(cardElement) or the Payment Element confirmation flow) and POSTs only the resulting token or PaymentIntent/PaymentMethod ID to the first-party endpoint.
- Treat any third-party
<script src="..."> loaded on a payment-collection page without an integrity attribute (Subresource Integrity, e.g. a sha256- hash) as a finding — cite PCI-DSS v4 requirement 6.4.3 (script inventory, script authorization, and integrity control) as the standard-based grounding. Do not accept "we trust this vendor" as a substitute for a visible integrity attribute or equivalent cryptographic verification.
- Stripe's hosted fields (
CardNumberElement, CardExpiryElement, CardCVCElement, PaymentElement) render inside sandboxed iframes controlled by Stripe, not merchant code — the browser's same-origin policy and the iframe sandbox boundary are what keep merchant JavaScript from ever reading raw PAN/CVV values. A missing-iframe-isolation finding applies when card fields are collected via manual elements with no sandboxed hosted-field equivalent in use.
References
Load these only when needed:
Response minimum
Return, at minimum:
- the payment-collection page(s), card-entry form markup, script tags, and/or client-side persistence/network calls in scope,
- ranked findings with file:line evidence, defect category (
raw-pan-input, card-data-persistence, self-posted-card-data, unsigned-third-party-script, or missing-iframe-isolation), the concrete data-flow trace (the raw <input>/.value read, the localStorage/analytics call, the POST body construction, or the missing integrity attribute), and a fix sketch matching Stripe's documented idiom (CardNumberElement, PaymentElement, stripe.createToken, or an integrity/SRI attribute),
- for every finding involving PAN/CVV/cardholder data exposure, an explicit statement of whether the value stays inside a Stripe-controlled iframe (safe) or is reachable by merchant JavaScript (unsafe) — never approve on the assumption isolation exists without tracing it,
- evidence level per finding (
repo evidence, documentation-based, standard-based, or inference), with structural risk findings explicitly labeled as structural risk, not as confirmed-exploited or confirmed non-compliant,
- verdict (approve / approve-with-notes / block),
- open questions or scope the review could not cover — explicitly restate that this is not a full PCI-DSS audit: server-side cardholder-data-environment segmentation, key management, network controls, and non-script requirement families are out of scope and require a dedicated compliance/infrastructure review.
