Checkout Page Script Monitor Against Card Skimming for Small Online Stores
A monitoring service for small online stores that inventories every script running on the checkout page, alerts when a script is added or changed, and helps the owner build a Content Security Policy that blocks card-skimming code. An intermediate web security final year project on headless browsers, CSP reports and change detection.
Intermediate
A small team, or one strong student willing to learn something new.2 semesters · 2 to 3 students
7 to ship
3 optional extrasSuggested stack
What you should ship
- A crawler that loads a store's checkout and payment pages in a headless browser on a schedule, records every script, iframe and network destination, and hashes each script body
- A script inventory where the owner marks each script as authorised with a written reason, and sees its source, first-seen date and hash history
- Change detection that alerts within one crawl when a new script appears, an authorised script's content changes, or data is sent to a new domain from the checkout page
- A CSP report collector endpoint that ingests browser violation reports at volume, deduplicates them and groups them by directive and source
- A policy builder that proposes a CSP from the inventory, runs it in report-only mode first, and shows what would have been blocked before the owner enforces it
- Plugins or setup guides for at least two common platforms, such as WooCommerce and a Shopify or custom Next.js storefront, to add headers and Subresource Integrity where possible
- A test lab of your own demo store with a harmless simulated skimmer injected through a compromised third-party script, used to measure detection time
If you have time left
- Behaviour signals for scripts, such as reading form fields on the payment page or hooking keyboard events, captured by instrumenting the headless browser
- An evidence export aligned with PCI DSS 4.0 requirements 6.4.3 and 11.6.1 for the store's payment provider or assessor
- An agency view for developers who manage many client stores
The problem small online stores have with card skimming
Card skimming on websites, often called Magecart after the groups that made it famous, does not break into the store's server in the usual way. The attacker changes a JavaScript file the checkout page loads: a compromised plugin, an analytics tag, a chat widget or a CDN-hosted library. The page looks normal, the order goes through, and a few lines of injected code quietly copy the card number and send it to the attacker's domain. The store owner finds out weeks later when the payment provider or bank traces fraud back to them.
Small stores are exposed because their checkout pages are full of third-party scripts that nobody reviews: themes, plugins, marketing pixels, reviews widgets. Payment card rules have caught up. PCI DSS 4.0 requirement 6.4.3 asks merchants to keep an inventory of scripts on payment pages, each authorised, integrity-checked and justified, and 11.6.1 asks for a mechanism that detects unauthorised changes to those pages. Large retailers buy tools for this. A shop on WooCommerce with one developer has no idea where to begin.
What already exists and the gap
- Cloudflare client-side security (formerly Page Shield): monitors scripts and connections on pages behind Cloudflare and alerts on changes. Useful, but full features sit in higher plans and require the site to be on Cloudflare.
- Report URI: a hosted CSP report collection and script monitoring service. Strong, but reporting volume drives pricing and the owner still has to understand CSP.
- Google CSP Evaluator: an open source tool that checks whether a policy is a real mitigation against cross-site scripting. It evaluates a policy; it does not build or monitor one.
- Commercial client-side protection vendors: products aimed at PCI compliance for larger merchants.
The gap is a tool for the small store and its freelance developer that combines an external crawler (works without changing the site), a readable inventory with approvals, and a guided path to a CSP that actually blocks exfiltration, without first needing to learn the whole CSP specification.
What you build
Roles: store owner (approves scripts, receives alerts), developer (configures headers and plugins).
- Add a store and prove ownership with a DNS record or a file on the site.
- Crawl: a scheduled headless browser session loads the cart and checkout pages (using a test product and no real payment), recording scripts, frames and outgoing requests.
- Inventory and approve: the owner reviews each script with a plain explanation of what it is and why it might be there, then approves or removes it.
- Monitor: every crawl compares against the approved baseline. New scripts, changed hashes and new destinations raise alerts by email and WhatsApp or Telegram.
- Enforce: the policy builder generates a CSP from approved sources, deploys it in report-only mode, collects violation reports, and helps the owner switch to enforcing mode once reports are clean.
The technically interesting part
The hard problem is telling a real threat from normal churn. Third-party scripts change often: marketing tags are rebuilt daily, some libraries are served with different content per request, and many scripts load further scripts dynamically. If every change is an alert, owners mute the tool. Design a change model that separates "same vendor, new version from an already approved domain" from "new domain" and from "approved file now sends form data somewhere new". Show your supervisor the alert volume on real public stores you crawl passively (only loading pages any visitor could load, and only with owner consent for monitoring) versus the planted skimmer in your lab.
The second part is ingesting CSP reports at volume. Browsers send noisy reports from extensions and injected content. Normalise, deduplicate and rate-limit them, and filter out noise that does not come from the site itself.
How to evaluate it
- Detection: in your lab store, inject a harmless simulated skimmer through a controlled third-party script in several ways (new file, modified existing file, dynamically loaded script). Report detection rate and time to alert.
- Alert quality: over four weeks on at least three consenting stores or your own demo stores with real third-party tags, count alerts per week and the share that needed action.
- Policy effectiveness: show the enforced CSP blocks the simulated skimmer's exfiltration request, and that normal checkout still works.
- Report ingestion: sustained reports per second on a small server.
- Usability: three store owners or developers approve an inventory and roll out a CSP; record time and sticking points.
Suggested plan
- Weeks 1 to 4: study skimming case studies, CSP and Subresource Integrity; build the demo store and lab.
- Weeks 5 to 10: crawler, script capture and hashing, ownership proof.
- Weeks 11 to 15: inventory, approvals and change detection.
- Weeks 16 to 20: CSP report collector and policy builder with report-only rollout.
- Weeks 21 to 26: platform setup guides, pilot, evaluation and write-up.
Path to a product
The first customer is a freelance developer or small agency that runs checkout pages for a handful of stores and needs to answer a payment provider's security questions. Price per monitored store per month, with a free single-page crawl as the entry point. Payment gateways and hosting companies serving small merchants are natural partners, since skimming losses land on them too.
Scope warning
Do not crawl or monitor stores without their owner's consent, and never submit real card details anywhere. Do not build a web application firewall or a malware scanner for server files. Keep the simulated skimmer inside your own lab and make it send data only to your own test endpoint.
Learn what you need on Sefism
- Frontend roadmap : how browsers load scripts, frames and third-party code.
- Backend cheat sheet : quick reference for the report collector and job queue.
- MDN: HTTP : security headers, CSP and Subresource Integrity from the source.
- OWASP Juice Shop : practise spotting client-side weaknesses in a safe, deliberately vulnerable store.
- ZAP by Checkmarx : inspect what your demo checkout page loads and sends.
Get help with this idea
Scoping a security project is mostly about deciding what you will not defend against and how you will prove the rest works. If you want a second opinion on scope, stack or your evaluation plan, a mentor can review it with you; you still build it yourselves. New to Sefism? Create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.