Online Store Security: Technical Measures for Businesses
17 min read
Online Store Security: Technical Measures for Businesses
To immediately reduce risk, implement TLS/HTTPS with HSTS, update your CMS and remove plugins you don't need, and always confirm payments server-side. For online store security, you start by closing off what attackers exploit most often: unencrypted traffic, outdated code, and trusting data from the browser. The rest follows in the explanation below.
In short:
Before releasing an order, the server should verify status, amount, and order number with the payment gateway; the browser's response alone doesn't confirm payment.
Only accept a payment gateway message with a valid signature, and a repeated message must never trigger duplicate execution or duplicate bookkeeping.
Require multi-factor login for administrators and employees; offer it as an option for customers, with authenticator apps and security keys preferred over SMS codes.
Store backups separately from the store itself, encrypt them, and test restoring them at least a few times a year, since an unverified backup is no guarantee.
Moxy-webmoxy-web.comStrengthen your online store's securityMoxy-web builds online stores and offers technical support and maintenance for businesses looking to improve their digital presence.Check out Moxy-web's services
Table of Contents
How to protect communication between your store and customers
How OWASP ASVS builds security into development from the start
The author's perspective: how we build security into projects
How to protect communication between your store and customers
Data traveling between a browser and your server can be intercepted if it isn't encrypted. That's why the first step is mandatory TLS across the entire store, not just checkout. The OWASP Developer Guide requires dropping support for plain HTTP, disabling SSL compression, and building connections on standard TLS configurations with valid certificates.
In practice, this means a few concrete settings:
Automatically redirect all HTTP traffic to HTTPS, and remove any content still loading over unencrypted connections.
Enable the Strict-Transport-Security (HSTS) header, so the browser itself refuses an unencrypted connection, reducing the chance of a man-in-the-middle (MITM) attack.
Set a Content-Security-Policy, telling the browser which sources it may load scripts from, making it harder to inject foreign scripts (XSS).
Disable old SSL/TLS versions and weak cipher suites, and regularly check and renew certificates before they expire.
Remove SSL-level compression from your configuration, since it opens the door to attacks that extract content from response size.
Compare it to a physical store: TLS is the locked door between the register and the street, and HSTS tells the browser to always use that secure connection. A good configuration is invisible, which is exactly why businesses often neglect it — until an incident happens.
Pro tip: After every change to your server or CDN, recheck your HSTS and CSP headers, since configuration updates can silently overwrite them.
For readers wanting a broader look at data protection, we've also written about website data security.
Why your CMS and plugins most often fail
Breaches into smaller stores can start with a plugin no one ever updated. SI-CERT warns that store owners often underestimate the security configuration of basic components. Attackers exploit outdated plugins and incorrect write permissions, letting them insert malicious code into a store — invisible forms that intercept card data, for example.
So build your CMS security in this order:
Update the CMS core and every plugin, then remove any you're not using. An inactive plugin can expand your attack surface without benefiting the business at all.
Choose plugins with active maintenance, a clear history of patches, and a small scope limited to the functionality you actually need.
Restrict write permissions on the server, so the web process can't modify its own program files. Restricting write access can make inserting a skimmer harder.
Set up file-integrity monitoring that alerts you when any system file changes without your action.
Run automated vulnerability scans and repeat them after every major update.
Forms deserve particular mention, since abuse often enters through them. You'll find more on this in our article on protecting forms from online abuse.
How to securely connect your payment gateway and webhooks
The payment flow is where mistakes turn into money instantly. The OWASP Cheat Sheet for payment gateway integration is clear: confirm payment status server-to-server, not based on what the browser reports back. A customer who manually calls your "payment successful" endpoint should never get a shipment.
Follow these rules in your integration:
Before releasing an order, have the server verify payment status, amount, and order ID with the gateway.
Only accept a webhook if its signature (HMAC) is valid, and verify it against a secret that never appears in the browser or in public code.
Make your processing idempotent: if the gateway sends the same message twice, the order must not be executed or booked twice.
Log every order status change, and set up alerts for unusual patterns, such as a high number of rejected signatures.
Don't store card data and don't write it into logs, if your payment provider handles it directly.
If you're also connecting your store to other business systems, it's also worth reviewing how to connect an ERP, POS, and CRM, since every additional connection adds a new point that needs securing.
Business logic as a source of vulnerabilities
Attacks on business logic can exploit rules a developer assumed rather than actually verified. The Business Logic Security Cheat Sheet warns that systems often fail to check whether a logged-in user has the right to perform this specific action on this specific resource. Your architecture needs to verify resource ownership on every single request.
Key rules for a store:
Calculate every security-relevant value — price, discount, and customer identity — on the server, and never accept them from the browser.
Every multi-step process, from cart to payment, should have server-side state that verifies allowed transitions.
Carry out critical changes in atomic transactions with locks or strict isolation, to avoid concurrent requests redeeming the same coupon twice.
For sensitive functions, consider rate limiting, making it harder to automate testing discount codes.
Pro tip: For every new step in checkout, ask yourself: what happens if the customer skips this step, repeats it, or calls it twice simultaneously?
Monitoring, testing, and incident response
Security without observation is guesswork. Logs need to capture who did what and when, while never containing sensitive data. OWASP's payment-gateway guidelines recommend logging with correlation identifiers, with the CVV code stripped from logs entirely.
Recommended plan:
Log IP addresses, timestamps, and correlation identifiers for every key event, from login to an order change.
Strip CVV and other sensitive data from your logs, since logs are often less protected than your database.
Run regular penetration tests and automated vulnerability scans, including tests for race conditions.
Prepare an incident-reporting process: SI-CERT, as the national response center, offers technical assistance, accepts reports at cert@cert.si, and its guidance covers forensics too.
After every incident, document what happened, what you changed, and who's responsible for the next review.
Forensic experience shows that simply having files and access monitored from day one often helps substantially.
How OWASP ASVS builds security into development from the start
Security bolted on after development finishes is always more expensive than security built in along the way. The OWASP Application Security Verification Standard 4.0 recommends building in security controls during an application's design and testing phases. ASVS Level 1 helps prevent basic oversights and supports compliance with PCI DSS, which matters for stores handling cards.
In practice, this means security becomes part of everyday work, not a one-time task before launch:
Translate ASVS requirements into your task list before development starts, not after.
Review every new feature handling customer data or payments from an abuse perspective, not just whether it works correctly.
Identify inherited code, libraries, and third-party plugins, and check whether they're actively maintained.
Test before launch, not only after your first incident, and re-review changes whenever your codebase changes.
For clients, this is also a business question. A store built to a proven standard can more easily demonstrate compliance and passes an external review faster. Since we build our own code rather than assembling stores from pre-built platforms, we can build these controls into the design from the start. You'll find more about our custom web applications on our site.
What incident reports reveal about trends
Statistics aren't a reason to panic, but they're a good gauge of where attacks are happening. SI-CERT's 2024 report cites 4,587 handled incidents, seven percent more than the year before. The report highlights growing phishing activity, more sophisticated phishing attacks against businesses, and extortion cases with large potential financial consequences.
Half-year cyber-incident reports round out this picture. The first half-year report for 2025 shows rising reports of online fraud, abuse of unprivileged accounts, and incidents tied to online shopping. Inadequate access management and web-application vulnerabilities are a common cause. The second half-year report highlights the dominance of fraud, extortion, and online-shopping-related incidents, with consequences including financial damage and business disruption.
For a store owner, three conclusions follow. First, attackers target smaller stores too, since they're often less protected. Second, the most common entry points are access credentials and vulnerable applications — both things you can control. Third, the consequence isn't just lost money but halted business, so it's worth preparing a response plan in advance.
At the EU level, rules are tightening. The Commission's guidance on the Cyber Resilience Act clarifies its scope, support periods, and reporting obligations. Per this source, reporting begins on September 11, 2026, with the main obligations applying from December 2027.
Managing user access and passwords
Many breaches don't require a single technical vulnerability — just stolen or guessable access. That's why every account in your store, from administrator to warehouse staff, needs to follow the principle of least privilege: everyone sees and changes only what their job requires.
Good access management has a few clear elements:
Every employee has their own account, never a shared one, so every action is traceable.
When a colleague or outside contractor leaves, revoke their access the same day.
Passwords require sufficient length, checking against known data breaches, and a ban on reusing the same password elsewhere.
Passwords are stored on the server only as hashed values using a slow algorithm, never as plain text.
The number of failed logins is limited, and unusual logins trigger an alert.
ASVS 4.0 includes recommendations for the credential lifecycle, multi-factor authentication, and principles for protecting against session attacks. Use it as a checklist, not a document to read once after launch.
For practical advice on protecting customers' personal data, see our guide to protecting user data as well.
Two-factor authentication for customers and administrators
A password alone is no longer a sufficient barrier. Two-factor authentication (2FA) adds a second proof that a person really is who they claim to be, so a stolen or leaked password alone doesn't open the door for an attacker. ASVS 4.0 treats multi-factor authentication as part of its credential-lifecycle recommendations.
When rolling out 2FA, distinguish between two groups of users:
Administrators and employees: 2FA should be mandatory with no exceptions, since a single compromised admin account means access to every order, customer, and setting.
Customers: offer 2FA as an option, ideally with a simple flow, since it has a decisive effect on trust and reduces account takeover.
When choosing a second factor, authenticator apps and hardware security keys are preferable to SMS messages, since they're less vulnerable to number interception. Also make sure your access-recovery process is secure, since that's often the weakest link: store recovery codes separately and require re-verification of identity.
Keep in mind that 2FA doesn't replace other measures. If an attacker already has a logged-in administrator's session, server-side permissions and restrictions still need to stop them.
Updates and backups
Updates close known holes, and backups limit the damage when something happens anyway. Both need to be regular and verified, not merely planned. As SI-CERT warns, outdated plugins in particular are a common path for attackers.
Set up an ongoing process for updates:
Designate a person responsible for tracking security patches for your CMS, plugins, and server software.
Test updates on a copy of the store first, then roll them out to production outside peak traffic hours.
Roll out critical security patches quickly, and less important ones on your regular schedule.
For backups, the rule is that a backup you've never restored isn't a backup — it's a hope. We recommend:
Back up files and the database automatically and regularly, adjusting frequency to how many orders you could afford to lose.
Store backups in a separate location an attacker with access to the store can't reach.
Test restoring them at least a few times a year, and log how long it takes.
Encrypt data in backups the same way you would the live database, since it contains the same sensitive data.
We build updates and backups into our support and maintenance services, so you don't have to handle this yourself.
Server protection and defending against DDoS attacks
A DDoS attack floods a store with fake traffic, so real customers can't reach checkout. Defense works in layers: no single measure covers everything, but together they substantially reduce the risk of an outage.
Basic building blocks of defense:
Place your server behind a content delivery network (CDN) or a traffic-filtering service that absorbs most malicious traffic before it reaches your server.
Set rate limits per IP address and on individual more expensive functions, such as search and login.
Cache static content and frequently requested pages, so the server doesn't process every request from scratch.
An application-level firewall blocks known attack patterns before they reach your store's code.
Harden the server: disable services you don't need, close unnecessary ports, and use separate accounts with minimal privileges.
Preparing in advance also matters. Write down who decides and who you call when traffic suddenly spikes: your hosting provider, a protection service, and SI-CERT if needed. If your store runs on shared hosting, the scope of defense differs from a dedicated server, so it's worth asking what DDoS protection is included at the time you choose hosting.
Time is critical: during an attack, every hour of downtime means lost orders, so prepare your response plan before you need it.
Encrypting sensitive data in the database
TLS protects data in transit, but once it lands in your database, different encryption needs to protect it. If an attacker gets hold of the database or a copy of it, encryption can render the data useless without the key. The OWASP Developer Guide treats data protection as an indispensable part of design, not just traffic.
When deciding what to encrypt, separate data by sensitivity:
Don't encrypt passwords — hash them with a slow algorithm designed specifically for that purpose.
Encrypt customers' personal data, such as addresses, phone numbers, and documents, either at the field level or across the entire database, based on risk.
Don't store card data if your payment provider can process it for you. What you don't store can't leak.
Encrypt backups the same way as your live database.
The most common mistake isn't choosing the wrong algorithm — it's how keys are handled. A key stored next to the encrypted data, or hard-coded into your codebase, can weaken that protection. Store keys separately from the database, rotate them regularly, and limit how many people can read them.
Beyond that, collect only as much data as your store genuinely needs. This can reduce risk and limit the damage if a leak does occur.
Security training for employees and users
Technical controls can fail if an employee clicks the wrong link. SI-CERT's 2024 report highlights growing phishing activity, including more sophisticated attacks on businesses, which is why training is part of technical protection, not an add-on.
Effective training is short, regular, and concrete:
Employees learn to recognize suspicious messages pretending to come from a supplier, a payment provider, or management.
Everyone knows where to report a suspicion, and that reporting won't get them in trouble, since a quick report limits damage.
Administrators and developers know the basics of secure coding, including the rules ASVS sets out.
Verifying a supplier's changed payment details and unusual orders doesn't happen through email alone.
Customers are also part of the balance. Clear notices about what your store will never ask for — a password by email, say — along with simple guidance for keeping an account secure, can help limit abuse. EU guidelines on labeling AI-generated content also help here, taking effect, per the Commission, on August 2, 2026, in response to risks like deepfakes and impersonation.
Repeat training regularly, test it with drills, and update your materials after every incident.
The author's perspective: how we build security into projects
Reviews of stores can turn up issues like outdated plugins, overly broad permissions, and payments confirmed by the browser instead of the server. That's why we don't treat security as an afterthought — we build it into the design, hosting, and maintenance from the start. At the start of a review, you can expect a conversation about what the store actually does, a configuration review, and a clear, prioritized list of actions.
— Ziga
A security review and Moxy-web's services
If you'd like to implement the measures above without an in-house team, we can carry them out for you: we build custom online stores and handle hosting and maintenance. Our reviews typically include checking TLS and headers, updating your CMS and plugins, the payment flow, and access permissions. Request a security review or write to us, and we'll tell you where to start. Pricing is available on request.
Frequently asked questions
Which measures matter most for protecting an online store?
First, make sure your traffic is encrypted with HTTPS and HSTS, your CMS is updated with no unnecessary plugins, and payments are confirmed server-side. These measures help address the most common attack paths. Details are covered in the OWASP Developer Guide.
Can I rely on the customer's browser to confirm a payment?
No, always confirm payment status server-to-server. Don't rely on data from the browser — confirm payment on the server. This process is described in the OWASP Cheat Sheet for payment gateways.
Where do I report a security incident involving my store?
Report an incident to SI-CERT, the national response center, at cert@cert.si. The center offers technical assistance, reporting procedures, and forensic guidance, as described in its cyber-security handbook.
Is two-factor authentication mandatory for store administrators?
Yes, it should be mandatory for administrator accounts. A single compromised account opens access to orders, customers, and settings, so a second factor substantially reduces that risk. Offer it to customers as an option.
How often should I test restoring a backup?
Test restoring it regularly, at least a few times a year, and after every major system change. A backup you've never restored is no guarantee you'll actually be able to use it when you need to.