You spend thousands on marketing, you optimize your product pages, you run Facebook ads, you finally see sales rolling in.
Then one morning you wake up to a fraud alert, customer credit cards are being used in another country, your payment processor is holding your funds, your reputation is destroyed.

This happens every single day, not to careless website owners, but to hardworking business owners who did not know their e-commerce site had gaping security holes.

After auditing hundreds of online stores, here are the ten vulnerabilities we find over and over again, month after month.

The E-commerce Security Reality Check

Before we dive into the list, let me share a concerning statistic, over 80% of e-commerce websites we test have at least one critical vulnerability, and most have several

These are not theoretical bugs, they are actively exploitable flaws that attackers use every day to steal customer data, hijack transactions, and deface websites
The most frustrating part, almost all of these vulnerabilities are preventable with basic security hygiene

Vulnerability 1: Outdated Core, Plugins, and Themes

This is the number one finding month after month, e-commerce sites running on outdated software
What we find:
1. WooCommerce sites running versions from 2022 with known remote code execution vulnerabilities
2. Magento installations that have not been updated in two years
3. Outdated PHP versions that reached end of life years ago
4. Plugins with critical CVSS scores that have patches available but not applied

Why this happens:
Store owners are terrified of updates breaking their carefully customized checkout flow, they postpone updates indefinitely, not realizing that attackers are scanning for outdated versions every single minute

Real impact:
We recently found an e-commerce site running WooCommerce 3.9 (released in 2019), there were 47 known critical vulnerabilities between that version and the current one, the attacker could take over the entire site with a single HTTP request

Fix it now:
1. Setup Auto-Updates (including minor releases).
2. Establish Maintenance Window (for major releases) for 2nd Tuesday of each month.
3. Use Staging Environment to Verify Updates Prior to Production.
4. Subscribe to Security Advisory Notifications for Your Platform.

Vulnerability 2: SQL Injection of Search and Product Filter Functions.  

Second on our list is the vulnerability of SQL injection, which has been around forever; and it is still causing problems with regard to custom-built e-commerce functionalities.

Examples of SQL Injection Vulnerabilities Found Include:
1. Search boxes that concatenate user input directly into SQL Queries - for Example as shown below.
2. Product filters - i.e., price range, product category, product attribute, etc., from the searching / purchasing process that have been coded incorrectly with respect to the input from the search box.
3. Custom reports that were created based on data from orders that have been incorrectly coded against SQL Databases.
4. Third-party plug-ins - i.e., nokia, quickbooks, etc., that have not coded the plug-in correctly against SQL Databases and/or written SQL with vulnerabilities.

An attacker will send in a specially crafted string through your search box that instead of returning a list of products, will instead return the names of Customers, Customer Addresses, Customer exposed Credit card Information to the Active Directory of your SQL Databases.

Real impact:
an SQL Injection vulnerability in their order tracking system resulted in attackers being able to extract just over 50,000 customer records containing everything from complete name and address to the last four digits of the credit card used.

To fix it: 
1. Whenever you perform a database query,you should always use prepared statements.
2. Never concatenate any user input when crafting an SQL query.
3. Automated scanners or similar tools can be helpful to identify SQL injection vulnerabilities.
4. If you are using an ORM framework be sure it supports automatic creation of parameterized SQL statements.

Vulnerability 3: Card Skimmers (Magecart) on the Checkout Page

This is the number-one e-commerce vulnerability, as it allows for the direct theft of payment information.

What we find are:
1. JavaScript inserted maliciously onto checkout pages.
2. Third-party scripts have been compromised, allowing for the capture of card data.
3. Theme files have back doors which allow for skimmer code to be loaded from an outside source.
4. Admin accounts that are hidden and provide ongoing access.

How attackers exploit it:
An attacker inserts a small piece of JavaScript code on your checkout page, and when the customer enters their credit card information, the code takes that information and sends it to the attacker, prior to the payment being completed.

Real impact:
a moderate-sized home goods shop had identified a skimmer in action without awareness for 3 months, meaning over 5,000 client credit card numbers were obtained, incurring £500K in chargebacks and fines on behalf of the store

How To Detect:
1. Outgoing Requests (Via HTTP) from the Checkout Page should be Monitored
2. Monitoring Scripts Loaded from Unexpected Domains should be Conducted
3. Review File Integrity for Unexpected Change (e.g., a script being added or removed) should be Conducted Regularly

How To Fix Now:
1. Implement Content Security Policy (CSP) Headers
2. Utilize Subresource Integrity (SRI) for Third Party Scripts
3. Monitor Changes On The Checkout Page Using File Integrity Monitoring
4. Red Secure Tech Will Provide 24/7 Emergency Skimmer Removal If You Are Already Compromised.

Vulnerability 4: Broken Authentication and Session Management

E-commerce sites have many user roles, customers, administrators, vendors, each with different access levels, broken authentication mixes them up

What we find:
1. Admin panel is accessible via the internet and has weak passwords
2. Session tokens can be found in the URL parameters (a logged-in session can be seen in your browser history).
3. When you try to log in but fail, you will not be locked out.
4. The password reset link that is sent to you is valid for an unlimited time.
5. Session identifiers are predictable.

How attackers use these vulnerabilities:
The attacker finds the admin panel, then uses weak or default passwords without locking the admin out after several attempts and successfully brutes his or her way into the admin panel. Once in, the attacker has complete control over the products, prices, and customer data in the database.

Real impact:
A hacker had access to an online furniture store´s administrator panel with the Url of /admin and the credential of admin123, allowing him/her to have changed the price of all items sold by the online furniture store to £0.01 and to place a large number of orders prior to being discovered.

How to resolve current issues:
1. Modify the URL for your admin panel so that it is different from its default location (or at the very least, move it somewhere that makes it difficult to guess its location).
2. This will provide protection against unauthorized users attempting to access administrator accounts by using a very strong and complex password, as well as requiring two-factor authentication (2FA). 
3. Limit the maximum number of times (5-10) that users can fail to log in before becoming locked out of their accounts (after which time they will need to contact the system administrator for support).
4. Be certain that your session cookies have the appropriate values for setting the HTTP Only attribute and the SameSite attribute on the cookie.
5. Avoid placing session tokens in the query-string portion of your application requests.

Vulnerability 5: Insecure Direct Object References (IDOR) 

Insecure direct object references (IDOR) are vulnerabilities that allow unauthorized persons to obtain another person’s data from the application by simply changing an attribute identifier (AID) embedded in either a URL or a form submission. 

Example of IDOR vulnerabilities:
1. The availability of order detail based on the order's numeric seq number as part of the HTTP request; e.g.,  /order?id=1001 and/or /order?id=1002 (fourth order).
2. The ability to download invoices without any authentication check (e.g., IDS of the legal titleholder).
3. The ability to access another user's profile page requesting that user's profile without verifying that the requesting user is the owner of that profile page.
4. All of the API endpoints used to retrieve customer information provide the requested information regardless of what ID is specified in the HTTP request. 

How attackers exploit it:
When an attacker places an order on your site, the attacker is assigned sequential order number 12345, and thus the attacker can modify the order number to 12344 and very easily view the complete details of orders belonging to another account's record including: the name of the order holder, their shipping address, and the items purchased.

Real impact:
When there was an IDOR vulnerability in the order lookup API of a large electronics retailer, attackers created a simple piece of software that automatically cycled through the order numbers in the order lookup API and downloaded the customer record for approximately 200,000 customers.

Mitigation actions:
1. Do not rely solely on the ID for authorization; always verify that the requesting user is the legal owner of the resource.
2. Where possible, use a UUID (Universally Unique Identifier) instead of a sequentially incrementing integer for the storage of record IDs.
3. Implement access controls on every API endpoint that is available for authenticated users.
4. Test every authenticated API endpoint that is reachable by more than one user account.

Vulnerability 6: XSS (Cross Site Scripting) - in Product Review's and User Profiles

When an attacker uses an XSS attack, they can insert malicious scripts into your web page that will execute inside of your customer's browsers.

What we found:
1. There is no restriction on the type of HTML (unescaped) characters that can be entered in product review fields.
2. Customer profile fields (billing address, company name, etc.) are not sanitized.
3. Search boxes return the user input without encoding.
4. When viewing admin panel note fields, the note is executed.

How an attacker can exploit it:
An attacker submits a product review containing a piece of malicious JavaScript. When another customer views this product, the JavaScript will be executed in their browser allowing the attacker to either steal the customer's session cookie, redirect them to a fake checkout page, or load a card skimmer.

Real-World Impact:
A beauty products store had an XSS vulnerability in their customer review system that allowed attackers to steal the session cookies from 500 customers and use them to make fraudulent purchases.

What You Need to Do Now:
1. All end-user-generated content should be encoded prior to display.
2. Use Content Security Policy headers.
3. Implement a Web Application Firewall that will detect XSS payloads.
4. All input fields should be validated and sanitized prior to processing.

Vulnerability 7:  File Upload Vulnerabilities:

E-Commerce websites use uploaded files as images for products, avatars for customers and to allow for the easy upload of digital files. Each of these upload types provides an avenue for malicious individuals to gain access to an e-commerce website. 

The following examples of file upload vulnerabilities:
1. A product image upload that allows a PHP file to be uploaded to the website as an image by renaming the image from a .jpg to .jpg.php file.
2. Customer avatar upload where the uploading user is not limited to what file type can be uploaded/validated.
3. A digital download section where the user is able to upload any type of file.
4. A return request form that allows for the user to upload a zip file that contains malicious software. 

How the Malicious User exploits these vulnerabilities:
An attacker can upload a web shell to the website, named (for example) product image, and has direct access to that upload location (example: /wp-content/uploads/shell.php) which gives the attacker the ability to run commands on the web server.

Real Impact:
A large digital marketplace allowed sellers to upload product files and was compromised when the attacker was able to upload web shells, and subsequently defaced 200 product pages, taking the website down for three full days.

How to Avoid This Issue:
1. Always validate the extension of the file and validate the actual content (using magic bytes) of the file.
2. Store uploaded files outside the web root directory.
3. Use a randomly generated and unguessable filename for each upload to the website.
4. Disable the ability to execute scripts from the upload directories.
5. Scan all uploaded files using an Anti-Virus product.

Vulnerability 8: Payment Gateway Configuration Problems.

Payment gateways represent the most valuable assets of an eCommerce website and any payment gateway mistake will be extremely harmful.

Examples of Misconfigurations:
1. The Gateway has an implementation of client-side JavaScript that contains API keys.
2. The Gateway has a production environment that allows transactions to be processed as "test."
3. The Webhook endpoints are not encrypted.
4. There is no ability to verify the signature on Webhooks being returned from the Gateway.
5. The Debug logs may contain customer's credit card numbers.

Attackers can exploit these vulnerabilities by accessing your Stripe API key via your JavaScript source code which allows them to issue refunds, create fraudulent new charges or otherwise obtain copies of customer's payment method tokens.

The real life ramifications were that an attacker was able to issue £50,000 worth of refunds before Stripe suspended a subscription box company's account because they had left the Stripe API key in client-side code.

Immediate Recommendations: 
1. Each application cannot contain an API Key in the client-side code; the API Key is used as part of the Application or server-based API calls to generate a response.
2. Each response to the API from Webhook calls must contain signature verification.
3. All production-time debugging logs must be disabled.
4. All API Keys must be changed on a regular basis.
5. Development API Keys and production API Keys must be different.

Vulnerability 9: Error Message Disclosure from Application

Error messages can be beneficial for troubleshooting your application, but they can potentially provide an attacker with additional information about your entire infrastructure. 

Some of the more common types of disclosures are:
1. Complete, verbose scripts that show full detail of the database names and structure of tables in your database.
2. When stack traces (error outputs) containing information about different types of files (e.g. source code, configuration files, etc.) are generated, they tend to include not only the locations of those files but also the versions of the software being used.
3. Login error messages that provide detailed descriptions such as; User Not Found, Invalid Password, etc.
4. Backup files (e.g. .sql, .zip, .tar) accessible via public sites.

How attackers can exploit it: 
For example, if an attacker were to enter a single quote character into a search text box, the application would generate an error based on the database structure it contains, which would then allow the attacker to perform a SQL Injection attack against the database. 

Real impact:
One particular wine retailer had a client database backup (in .sql format) located in the root directory of its e-commerce website, the file included sensitive information including customer full names, customer addresses, hashed password for customer accounts, and order history; anyone knowing the filename could download the file from this location without restriction.  

Fix it now:
1. Stop displaying detailed error messages when running a production system or when logging to a file.
2. Use log files instead of displaying error messages on screens.
3. Create a generic error page for all types of exceptions (see below).
4. Remove any back up file from any publicly available directory.
5. Check for any security related files that may be exposed on a frequent basis.

Vulnerability 10:  APIs Have Weak Security

Online retailers frequently depend on dozens of APIs in their business, from payment processors to shipping calculators, inventory management, marketing automation tools, etc., and many of these could be exploitable by attackers.

Where we often find vulnerabilities in APIs:
1. API endpoints that do not require authentication (so anyone can access them);
2. API keys have been set with permission that are far too significant and would be exploitable by attackers (like granting read and write access instead of read access only);
3. There are no rate limits on API calls (enabling an attacker to brute force API keys);
4. API responses contain sensitive information (such as customer email addresses or order information); and
5. All API traffic uses unencrypted HTTP instead of encrypted HTTPS.

How do attackers exploit these vulnerabilities?
For instance, an attacker locates your unauthenticated product API, builds a script that downloads an entire copy of the product catalog, including the cost of products and, thus, is able to calculate your margins, enabling the attacker to undercut you on every product sold.

What is the consequence of this vulnerability?
There was a sports equipment store that had an unauthenticated customer API that returned the entire record for every customer. The hacker downloaded 100,000 customer records that included customer names, addresses, and phone numbers.

How to fix it:
1. Authenticate all API calls
2. Assign the minimum required permissions (Least Privilege Access)
3. Establish a Rate Limit for calling an API on all endpoints
4. Limit the amount of information returned by the API to only what is necessary to perform the intended function of the API.
5. Require that all API traffic use an encrypted HTTPS connection.
6. Audit Access Logs on a regular, recurring basis

E-commerce Security Checklist

This checklist should be completed monthly to ensure your online store is protected.

When to Call a Professional

If you have not audited your e-commerce site in the last six months, assume you have vulnerabilities, attackers are scanning your site right now
Red Secure Tech offers comprehensive e-commerce security audits that identify all ten of these vulnerabilities and more, their penetration testers simulate real-world attacks to find holes before criminals do.

If you are already hacked or suspect a compromise, their emergency incident response team is available 24/7 with a 4-hour first response time and a no fix, no charge policy

Conclusion: Don't Wait for the Breach

We find these vulnerabilities in e-commerce sites every single month, not because store owners are lazy, but because e-commerce is complex and security is rarely a priority until something breaks
By then, it is often too late

Run a security audit today, check for these ten vulnerabilities, patch what you find, and make security a regular part of your e-commerce operations
Your customers trust you with their credit cards, their addresses, their identities, honor that trust by keeping their data safe

FAQ Section

How often should I scan my e-commerce site for vulnerabilities?

At minimum, run automated scans weekly and manual penetration tests quarterly, after any major code change or plugin update, run a full scan immediately

What is the most common way e-commerce sites get hacked?

Outdated software is the number one entry point, attackers scan for known vulnerabilities in old versions of WooCommerce, Magento, and plugins, the second most common is stolen admin credentials from weak passwords or reused passwords from other breaches

Can a hacker steal credit cards from my site without me knowing?

Yes, card skimmers (Magecart) can run for months without detection, the attacker injects a small script into your checkout page that silently exfiltrates card data, you will not know until customers report fraudulent charges or your payment processor notifies you

What is the cost of an ecommerce security audit?

The costs depend on multiple factors, including complexity of the site, number of products, custom features, and required compliance standards. For you to receive an estimate that is specific to your e-commerce site, use Red Secure Tech's instant cost calculator.

If my e-commerce is built on Shopify, am I protected against the vulnerabilities mentioned above?

Shopify provides its customers with server security, payment card industry (PCI) compliant processing and core updates to its platform. However, the merchant itself is still responsible for ensuring the security of third party apps, any custom code in their liquid templates, the security of their administrator accounts (multi-factor authentication and strong passwords), and the effective management of their API keys, so we routinely identify vulnerabilities within Shopify stores.