E-01 · BUILDING

An e-commerce security scanner shop owners can act on

Small online shops rarely know what an attacker can see from the outside. Existing scanners dump long technical lists. I'm building one with a graphical interface that ranks findings by real-world risk and tells the owner which rule they break and what to fix first.

context: bachelor thesis, TSI
defence: 2027
status: in design
mode: passive by default

Why it matters now

Since 2025, PCI DSS v4.0.1 requires shops to keep an inventory of every script on their payment page (requirement 6.4.3) and to detect when that page is tampered with (11.6.1). Most small merchants have never heard of either.

Card-skimming attacks exploit exactly those gaps, and one unlisted third-party script on checkout is enough.

How it works

COLLECTPublic signalsDNS, certificates, headers, page scripts, software versions
ENRICHThreat intelligencePublic reputation and vulnerability APIs
SCOREReal-world riskCISA KEV, EPSS, CVSS
MAPRules brokenPCI DSS, OWASP ASVS, ISO 27001
SHOWGUI and reportsFindings in the interface, exports for developers and owners

Each stage is a separate module, so new checks or frameworks plug in without touching the rest. Shop owners work in the graphical interface; developers can export the technical report. An optional AI module turns findings into plain-language fixes for non-technical owners.

The interface

concept · example data

Shop scanner

example-shop.lvScan again

5 findings · sorted by real-world risk

1 high3 medium1 low

HIGHUnlisted third-party script on checkoutPCI DSS 6.4.3

MEDIUMNo Content-Security-Policy headerASVS 14.4

MEDIUMJavaScript library with a known vulnerabilityASVS 14.2

MEDIUMTLS certificate expires in 12 daysTLS

LOWServer version shown in response headersASVS 14.3

HIGHcheckout page

Unlisted third-party script on checkout

A script from a domain you haven't approved runs on the payment page. This is how card skimmers get in.

breaks PCI DSS 6.4.3 · 11.6.1

Fix · approve or remove the script, then turn on tamper alerts.

Mark as fixed

The main screen as I'm designing it. Findings are sorted by real-world risk, and opening one shows the rule it breaks and the fix in plain language.

What the owner gets

There's no command line. In the interface, each finding looks like the example below.

example-shop.lv/checkout     (example output)
finding   unlisted 3rd-party script on payment page
severity  HIGH · actively exploited pattern
breaks    PCI DSS 6.4.3, 11.6.1
fix       approve or remove the script, enable tamper alerts

Built to be safe to run

Passive by defaultOnly public data. Active probing stays off unless the user proves they own or are authorised to test the site.
Bring your own keysNo API keys ship with the tool. Users supply their own and stay within each provider's terms.
Secure by its own standardTimeouts and rate limits on every request, careful parsing of API responses, no secrets in logs, protection against server-side request forgery, and dependency and static analysis in CI.
AI-assisted, human-ownedMuch of the code is written with AI help. The architecture, threat model, scoring decisions, reviews and tests are mine, recorded as decision records.

Where it stands

DONETopic approved, October 2026
NOWArchitecture and threat model
NEXTBuild the modules and evaluate them on test shops
2027Thesis defence, then an open-source release under Apache-2.0