An online shop can be hardened on every layer -- the PHP interpreter, the web server, the file permissions -- and still be lost through the front door: through an admin login with a guessed, reused or phished password. Compromised credentials are behind 88 percent of attacks on web applications (Verizon Data Breach Investigations Report 2025), and the abuse of valid credentials is the single most common initial access vector at 22 percent (Verizon Data Breach Investigations Report 2025). Classic server hardening, however, usually stops below the application: it secures the operating system, not the identities that log into the shop backend. That is exactly where this article picks up. It covers securing the backend itself: multi-factor authentication for all administrators, roles following the least-privilege principle, clean offboarding, brute-force and rate limiting at the login, session hardening and phishing-resistant sign-in methods. Unlike server hardening for shops, which looks at PHP, the web server and permissions, the focus here is on identity and access control -- the layer where most breaches actually begin.
Where Hardening Stops at the Login
Server hardening is necessary and effective, yet it protects a different layer. A restrictive PHP configuration, a cleanly separated web server and file permissions following the least-privilege principle make it harder for an attacker to run code out of a vulnerability or to move laterally. None of these measures, however, stops someone who logs in with valid credentials -- to the system this looks like a legitimate administrator doing their work. That shifts the real point of failure from the infrastructure to the identity. The picture matches the situation of many operators: small and medium-sized enterprises meet on average only around 56 percent of the baseline requirements for IT security (BSI report on IT security in Germany 2025), and access control in the application backend is regularly among the open items.
That the login is the actual weak point shows in the distribution of incidents. Around 60 percent of all breaches involve the human element (Verizon Data Breach Investigations Report 2025) -- a phished password, a credential that surfaced in a third-party leak and was reused in the shop, a support account without a second factor. The OWASP Top 10 lists exactly this class as its own risk category: 'Identification and Authentication Failures' (A07) bundles credential stuffing, brute force, weak or default passwords, exposed session identifiers and missing multi-factor authentication (OWASP Top 10). Hardening only the server layer leaves open precisely the door most attackers come through.
The Login Is the Front Door
MFA for Every Admin Login
Multi-factor authentication is the single most effective measure against the vast majority of password-related attacks. The OWASP Credential Stuffing Prevention Cheat Sheet calls MFA by far the best defense and points to an analysis according to which it would have prevented 99.9 percent of automated account takeovers (OWASP Credential Stuffing Prevention Cheat Sheet). The reason is simple: even if a password was guessed, reused or phished, the attacker lacks the second factor. What matters, though, is which second factor is used -- because not every method withstands a targeted phishing attack.
| Method | Protective effect | Assessment |
|---|---|---|
| FIDO2 security key / passkey | binds the login cryptographically to the domain | phishing-resistant, recommended for admins |
| Authenticator app (time-based code) | additional one-time code from an app | much better than password alone, but phishable |
| SMS or email code | one-time code over a second channel | interceptable, only as a transitional measure |
| Push confirmation | approval by tapping on the smartphone | convenient, but prone to fatigue attacks |
The difference is not theoretical. An SMS or app code can be requested because the user enters it on a cloned login page -- and that happens fast: the median time between opening a phishing email and clicking is just 21 seconds, and about 49 seconds in total until credentials are entered (Verizon Data Breach Investigations Report 2025). Phishing is behind 16 percent of breaches (Verizon Data Breach Investigations Report 2025). Phishing-resistant methods such as FIDO2 keys or passkeys bind the login cryptographically to the real domain, so a fake page cannot make use of the factor -- which is why the Cybersecurity and Infrastructure Security Agency explicitly recommends phishing-resistant MFA and classes SMS, OTP and push methods as bypassable (CISA). Even one added factor has a marked effect: in a study by Google, a device-bound confirmation blocked all automated bot sign-in attempts and 99 percent of bulk phishing attacks (Google Security Blog).
MFA for Every Login, Not Just the Main Admin
Least Privilege: Roles and Rights Hygiene
Not everyone who works in the shop needs administrator rights. The least-privilege principle states that each account receives only the rights its task demands -- and none beyond that. In practice this principle often collapses, because it is more convenient to give everyone the full administrator role than to tailor rights individually. The price is paid only in an incident: if an editorial or support account that wrongly holds full access is taken over, the attacker faces the entire system instead of a narrowly bounded section. Cleanly scoped roles shrink the attack surface of each individual account.
| Role | Typical task | Appropriate rights |
|---|---|---|
| Owner / administrator | system and user management | full access -- few, named accounts |
| Editorial / content | products, texts, categories | manage content, no system settings |
| Support / service | orders, customer inquiries | order and customer data, no plugin access |
| Accounting | invoices, payment reconciliation | read financial data, no catalog rights |
| Development / agency | maintenance, updates, fixes | time-limited, individual access with logging |
- Assign every backend account to a defined role -- no individually pieced-together special rights that nobody can trace anymore.
- Limit the administrator role to a few named individuals; avoid shared accounts such as 'admin' or 'editor'.
- Review rights regularly against the actual task and roll back accumulated extra rights (rights decay).
- Run agency and external service-provider access as separate, time-limited accounts -- not via a shared password.
- Log changes to roles and rights so it stays traceable who received which permission and when.
As Much Right as Needed, as Little as Possible
Offboarding and the Decay of Rights
Access is created continuously, but it rarely disappears on its own. Employees move on, interns leave, an agency finishes its project, a payment or shipping service is swapped out -- and the associated accounts often stay active. Such orphaned access is especially dangerous because nobody notices it anymore: its password ages, may end up in a data leak, and no one spots a later sign-in because the account is no longer tied to an active user. Structured offboarding closes this gap by treating the removal of rights as bindingly as their granting.
- When a person leaves, deactivate their backend account promptly and do not merely change the password.
- Deactivate or time-limit service-provider accounts after a project ends -- with a fixed expiry date instead of open-ended access.
- Inventory service and technical accounts (API keys, integration access) and revoke them when switching providers.
- At regular intervals, review all active backend accounts and question any without a clear owner.
- Dissolve shared passwords and replace them with personal accounts so every sign-in stays attributable to a person.
Orphaned Accounts Are Silent Doors
Brute Force and Rate Limiting at the Login
Where MFA does not (yet) apply everywhere, the login itself becomes the target of automated attacks. In credential stuffing, bots try lists of credentials captured from third-party leaks at scale; in password spraying, they test a few common passwords against many accounts. Both rely on some account using a reused or weak password -- and both are why the abuse of valid credentials remains the most common initial access vector at 22 percent (Verizon Data Breach Investigations Report 2025). Where MFA is not possible, the OWASP Credential Stuffing Prevention Cheat Sheet recommends several layered protections that together form a resilient defense (OWASP Credential Stuffing Prevention Cheat Sheet).
- Rate limiting: cap the number of login attempts per IP address and per account within a time window, so volume runs into nothing.
- Delay and lockout: after several failed attempts, increase the wait time (backoff) or temporarily lock the account.
- Check against known leaks: screen new and changed passwords against lists of compromised credentials and reject them.
- Bot detection: on suspicious behavior, require an additional hurdle such as a CAPTCHA to slow automated attempts.
- Neutral error messages: on a failed login, do not reveal whether the username or the password was wrong, to make it harder to enumerate valid accounts.
# Throttle the login endpoint against brute force and credential stuffing
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location = /admin/login {
limit_req zone=login burst=3 nodelay;
limit_req_status 429;
try_files $uri /index.php$is_args$args;
}
# Additionally restrict the admin area to known networks
location /admin/ {
allow 203.0.113.0/24; # office network
deny all;
}Rate limiting only shows its value once the login attempts are also observed: a sudden rise in failed logins from many IP addresses is a clear signal of an ongoing attack. That is why throttling belongs together with monitoring of admin sign-ins that alerts on such patterns. How the same observation idea carries over to the purchase path is shown in the article on checkout and transaction monitoring.
Session Hardening and Secure Sign-In
Securing does not end with a successful login -- it shifts to the session. An attacker who captures a valid session identifier, for instance through an injected script or an insecurely set cookie, can simply skip multi-factor authentication because the sign-in has already happened. The OWASP Top 10 explicitly lists exposed session identifiers and weak session management among the authentication failures (OWASP Top 10). Session hardening ensures that a session is hard to steal and quickly worthless after a theft.
Set Cookie Flags Consistently
Serve session cookies with HttpOnly, Secure and a suitable SameSite value so they cannot be read by script and are only transmitted over HTTPS.
Renew the Session ID After Login
Issue a new, random session identifier with high entropy on sign-in to prevent session fixation -- the identifier does not belong in the URL.
Idle and Absolute Timeout
End sessions after a period of inactivity and additionally after a fixed maximum duration, so a forgotten sign-in does not stay open indefinitely.
Separate, Protected Admin Path
Serve the backend over its own path, restrict it to known networks where possible, and let logout discard the session cleanly on the server.
; Harden session cookies
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = "Lax"
session.use_strict_mode = 1
session.use_only_cookies = 1
session.gc_maxlifetime = 1800 ; idle timeout in secondsA stolen session unhooks multi-factor authentication, because the sign-in has already happened. Short timeouts, clean cookie flags and a new session identifier after login make sure a captured session opens only a brief window.
Access Hardening as an Ongoing Building Block
Access control is not a state you establish once but one that shifts with every new account, every departing service provider and every software update. At an average of 119 new vulnerabilities per day -- an increase of 24 percent over the previous year (BSI report on IT security in Germany 2025) -- new avenues keep appearing where the sign-in layer can be affected too. Who carries the risk? Predominantly smaller operators: of 950 ransomware attacks in the reporting period, around 80 percent hit small and medium-sized enterprises (BSI report on IT security in Germany 2025) -- and ransomware often begins with exactly the compromised credentials this article is about.
Recurring Access Reviews
At fixed intervals, review all active accounts and their roles, close orphaned access and roll back accumulated rights.
Monitoring of Admin Logins
Watch failed sign-ins, unusual times and new locations, and alert on anomalies -- rather than leaving it to chance.
MFA and Role Upkeep
Create new accounts with MFA and a fitting role from the start, and keep the phishing-resistant methods for administrators current.
- Keep MFA mandatory for all backend accounts and work toward phishing-resistant methods for administrators.
- Review roles and rights at fixed intervals and scope them back following the least-privilege principle.
- Run offboarding as a fixed process: promptly deactivate accounts of departed people and ended service providers.
- Keep login rate limiting, password leak screening and neutral error messages active and verify their effect.
- Re-check session settings -- cookie flags, timeouts, session ID renewal -- after every major update.
A hardened backend thus emerges from the interplay of many small, ongoing measures -- and from their connection with the other building blocks of maintenance. Access hardening reaches into the ongoing security updates as well as into the HTTP security headers that keep injected scripts from siphoning off session data, and into patch and CVE management. For regulated shops it touches the evidence required by the NIS2 obligations for online shops and the PCI DSS monitoring of payment-page scripts. And if a login is compromised after all, a prepared emergency plan for a hacked website together with committed SLA response times decides how quickly the damage is contained. As part of an SLA maintenance contract and our full managed maintenance services, one-time securing becomes a state that stays maintained across ongoing Shopware operations.