Skip to content
Proactive security updates

Security

Shops process payment and customer data and are permanently exposed on the internet — they are scanned automatically for known weaknesses. This category covers day-to-day protection: applying security updates promptly, hardening server and application, access protection with strong methods and two-factor authentication, permissions for editors and service providers, protection against bot attacks on login and checkout, and detection of malicious code. Added to this is preparation and procedure in an emergency: verifying backups, documenting incidents, knowing reporting duties, resetting credentials. We describe measures that can be sustained with reasonable effort and deliberately avoid promises of absolute security. We additionally cover which traces an attack leaves and how to tell whether an incident is closed or merely paused.

Supply-chain attack through a patch versionMini Shai-Hulud: 1,055 compromised versions across 502 packages in npm, PyPI and Composer1. Registry2. Fresh version3. Controls in maintenancenpm: 1,048 versionsPyPI: 6 versionsComposer: 1 version502 packages across three ecosystemsPatch version4.2.7 with preinstalllooks harmlessLockfile + hashno rangesInstall scriptsdisabledCooldown7 daysRegistry mirrorno direct pullHarvested at install time (preinstall)CI/CD secretsDeploy accessPayment API keysRegistry tokensRunner memory read, secret masking does not help (Microsoft Security)SBOM inventory: Are we affected?PackageVersionStatusstorefront-theme4.2.7affectedbuild-toolchain2.9.1checkedpayment-lib1.4.0checkedWithout an inventory, the question becomes a manual hunt1,055versions502packages61,274tokens invalidated0CVE recordsSources: Infosecurity Magazine, Microsoft Security, Cloud Security Alliance, Unit 42, CISA
Security Jul 22, 2026

Supply-Chain Attacks: Securing Shop Dependencies

Mini Shai-Hulud arrived via patch versions: 1,055 versions, 502 packages, no CVE. How to secure lockfiles, install scripts, registry mirrors and tokens.

14 min read
Hardening Security Headers: from Report-only to Enforce1Report-onlyMeasure headers, block nothingContent-Security-Policy-Report-Only2AnalyzeCheck violations, allow sourcesreport-to / report-uri3EnforceSwitch the policy onContent-Security-PolicyHeader set on the OWASP baselineContent-Security-PolicyenforceStrict-Transport-SecurityactiveX-Content-Type-OptionsnosniffReferrer-PolicysetPermissions-PolicysetHeader adoption on the web22%CSP shareHSTS36%X-Content-Type-Options50%Referrer-Policy17%Permissions-Policy3.7%Ongoing header care: regression check after every updateUpdatePolicy breaks?Measure report-onlyEnforceCSP and HSTS first, then X-Content-Type-Options, Referrer-Policy and Permissions-Policy
Security Jul 15, 2026

HTTP Security Headers: Secure Shops with CSP and HSTS

Security headers like CSP and HSTS are not a one-time setup. Introduce them in report-only mode, harden to enforce and keep them stable across updates.

12 min read
Checkout Script Integrity - Block Web SkimmingThird-Party Scripts (6.4.3)Inventory with integrity checksanalytics.jsSRI verifiedpayment.jsSRI verifiedchat-widget.jsCSP allowedcdn-lib.jsSRI verifiedskimmer.jsCSP blockedshop.de/checkoutCheckoutCard number4716 24** **** 8391Expiry date09/28Security code (CVV)* * *Pay nowForeign scripttries to read card number and CVVand send it to a foreign domainblocked by CSP and SRIloadedmonitoredTamper Detection (11.6.1)Integrity checks at the checkout4/54 allowed1 blockedIntegrity confirmedCheck interval: 7 days!1 tampering blockedAlert sent to teamFour Layers of Checkout ProtectionScript inventorySubresource IntegrityContent Security PolicyTamper detectionContinuous integrity monitoring detects tampering before payment data leaksScript inventory | SRI | CSP | tamper detection per PCI DSS 4.0
Security Jul 8, 2026

Magecart Protection: Stop Web Skimming at Checkout

Web skimming steals card data right in the browser. See how a script inventory, Subresource Integrity, CSP and tamper detection per PCI DSS 4.0 stop the attack.

13 min read
The 2026 Patch Window: 5 Hours to AttackFrom a vulnerability becoming known to automated mass exploitationHour 0~15 minHour 5Hour 24Day 7DisclosureThe vulnerabilitybecomes publicFirst scanningBots scan from ~15 minfor targets (Unit 42)Median: 5 hoursto the first activeexploitation (Patchstack)45% in 24 hrsof heavily exploitedflaws (Patchstack)How fast exploitation happens20%within 6 hours (Patchstack)45%within 24 hours70%in 7 daysNot achievable by handNo unattended shop patches in 5 hoursovernight by hand46% of flaws are still unpatchedat disclosure (Patchstack)Managed maintenance closes the window automaticallyFeed monitoring - virtual patching - staging test - emergency patch with rollback - around the clock5 hrsmedian to attack11,334flaws 2025 (Patchstack)91%in plugins (Patchstack)~15 minto first scan (Unit 42)
Security Jun 29, 2026

WordPress Patch Window: 5 Hours to Attack

In 2026 the patch window has shrunk to a median of 5 hours. Why no self-maintained shop keeps up manually and how managed maintenance patches automatically.

14 min read
WAF and bot management: every request is inspectedIncoming trafficReal customersbrowser, mobileGood botssearch, AIBad botsscrapers, attacksWAF and bot managementSignatures / OWASP CRSRate limitingBot score / behaviourGeo / IP reputationChallenge / CAPTCHAAllowed throughcustomers and good bots50.4%human traffic 2023 (Imperva)Blocked / challengedattacks and fake traffic32%bad bots 2023 (Imperva)Why ongoing protection belongs to maintenance67.5%bad bot traffic inGermany (Imperva 2024)+250%account takeoverattacks 2024 (Kasada)+108%more DDoS attacks2024 vs 2023 (StormWall)57.5%bot share of web2026 (Cloudflare)
Security Jun 26, 2026

WAF and Bot Protection in Live Shop Operation

WAF and bot management as part of maintenance: how to protect your shop against automated attacks, scraping and fake traffic in live operation.

13 min read
CVE management pipeline: from alert to applied patchFour phases with clear ownership instead of an uncontrolled patch flood1. DetectCVE feeds and advisoriesInventory per shop componentSBOM and dependenciesKEV cross-check (CISA)48,185 CVEs 2025 (Zafran)2. PrioritizeCVSS severityEPSS exploitation riskExposure and contextBusiness impact shop~30% used on day 0 (VulnCheck)3. TestStaging clone of productionApply patch and verifyRegression test checkoutRelease gateno live risk (project)4. DeployMaintenance windowRollback readyMonitoring afterwardsLogged in the recordauditableThe patch gap in numbers26%critical KEV flaws fully fixed (Verizon)43 daysmedian to patchStructured in the maintenance contractFixed response times instead of chanceDetect - Prioritize - Test - Deployevery step documented and auditableVulnerability exploitation is the leading initial access with a 34% rise (Verizon DBIR 2026)From reactive chasing to a predictable patch cycleInventory - risk scoring - staging test - maintenance window with rollback - record
Security Jun 22, 2026

CVE Management for Online Shops: Plan Patches

Security patch and CVE management for online shops: detect vulnerabilities, prioritize by risk, test on staging and deploy patches in a controlled way.

14 min read
Malware Scan Dashboard -- File Integrity and ThreatsScan coverage14,812 files checked100%14,806 cleanIntegrity confirmed!6 findingsQuarantine activeFile Integrity Diff (expected/actual)Compared against signed reference hashes~ public/media/logo.php Hash mismatch!+ var/cache/_t8x.php New, unsigned!~ index.php Inline script injected= core/framework/* Unchanged= vendor/* Unchanged3 deviations, 14,806 files identical to referenceDetected ThreatsSKIMMERCard skimmer in checkoutreads payment field, sends to foreign domainBACKDOORWeb shellvar/cache/_t8x.php command executionINJECTIONSEO spam redirectinline JS redirects mobile trafficAll findings isolated -- cleanup recommendedScan pipelineHash compareSignature and heuristicsQuarantineAlert and reportDaily full scan plus real-time integrity check of the payment pageCompromised shops usually contain at least one additional hidden backdoorFile integrity | Skimmer detection | Backdoor hunting | Quarantine | Post-incident hardening
Security Jun 15, 2026

Malware Scanning and Cleanup for Online Shops

Detect and remove skimmers, injected scripts and backdoors: file integrity monitoring, structured cleanup and post-incident hardening for online shops.

14 min read
Server Hardening for Online Shops: Layer by LayerLeast privilegeMinimize attack surfaceHardening layers (defense in depth)1PHP configurationexpose_php Off - display_errors Off - disable_functionshardened2Web serverserver tokens off - TLS 1.2/1.3 - HTTP/2 - autoindex offhardened3File permissions644 files - 755 folders - no write access to codehardened4Security headersHSTS - CSP - X-Content-Type-Options - Referrer-Policyhardened5Firewall and accessports closed - SSH key not password - Fail2ban - WAFhardenedPatch disciplineClose known gaps promptlytime-to-exploit 2023 averaged 5 days (Mandiant)Review configurationremove default accounts - defaults - open services90% of tested apps had a misconfiguration (OWASP)PHP configuration | web server | file permissions 644/755 | HSTS and CSP | firewall | least privilege | patch management
Security Jun 12, 2026

Server Hardening for Shops: PHP, Web Server, Rights

PHP configuration, web server, file permissions, security headers and least privilege: how to harden your online shop server step by step, layer by layer.

13 min read
Backup Lifecycle Within the GDPR Framework1. Legal BasisArt. 6(1)(f)Legitimate interestProtect data integrity2. EncryptionAES-256 at restTLS 1.3 in transitArt. 32 measures3. EU StorageData processingArt. 28 DPANo third-country transferTension: Retain (commercial law) vs. Erase (Art. 17)RetainInvoices 10 years (Sec. 147 AO)Business letters 6 years (Sec. 257 HGB)Legal duty as retention groundArt. 17(3)(b)EraseRight to erasure (Art. 17)Storage limitation (Art. 5(1)(e))Deletion concept by periodsBackup: caught up on rotationActive DataErase immediatelyon data subject requestBackup SnapshotProtected, isolatedno direct accessRotationDeletion iscaught upRestoreRe-deletiondocumentedGoal: balance availability (Art. 32) and storage limitation (Art. 5)
Security Jun 5, 2026

GDPR-Compliant Data Backup and Retention for Shops

Reconcile GDPR and backups: legal basis, retention periods, deletion concept, right to erasure, encryption, data processing agreements and EU storage location.

13 min read
Securing Shop Admin Access: MFA, Roles, Login DefenseWhy access matters88%Attacks using stolen credentials22 % start with credential abuse16 % start with phishing60 % involve the human elementMFA methodsphishing-resistantFIDO2PasskeyHardware keybinds the login to the domaineasier to bypassSMS codeOTP appPushinterceptable via phishing (CISA)Least-privilege rolesOwner / AdminFull accessEditorialContentSupportOrdersAccountingInvoicesno shared super-admin for everythingLayered login defense -- every sign-in passes the chainLogin attemptCredentialsRate limitingPer-IP cadenceMFA checkphishing-resistantRole checkLeast privilegeSessionshort timeoutsMFA, least-privilege roles, rate limiting and session hardening interlockas an ongoing part of the maintenance contract -- not a one-time setup
Security May 29, 2026

Securing Shop Admin Access: MFA, Roles, Login Defense

Compromised credentials are behind most attacks. Secure your shop backend with MFA, least-privilege roles and login defense that holds across updates.

12 min read
PCI DSS 4.0.1: Inventory and Prove Payment Page ScriptsScript Inventory - Requirement 6.4.3ScriptAuthorizedIntegrityanalytics-tag.jsSRItag-manager.jsCSPchat-widget.jsCSPpayment-sdk.jsSRIunknown.jsmissingTamper Detection - Requirement 11.6.17daysWeekly check activeLast check: today!1 deviation detectedEvidence - Audit Trail (log)04.05.Inventory approved08.05.CSP rule added11.05.unknown.js blocked + alertCompliance as ongoing maintenance, not a one-off projectInventory (6.4.3)CSP / SRICheck (11.6.1)EvidenceScript inventory - CSP/SRI - weekly tamper detection - documented evidence (PCI DSS 4.0.1)
Security May 11, 2026

PCI DSS 4.0.1: Monitoring Payment Page Scripts

Since 03/2025, PCI DSS 4.0.1 requires a script inventory (6.4.3) and weekly tamper detection (11.6.1) on payment pages. How to prove it with evidence.

13 min read