7 of 7
3 weeks
0 days
Overview ( website security case study)
What we solved: Security
| Business | Ecommerce retailer, Texas. 800+ orders a week |
| Platform | WordPress, with plugins, custom code and integrations added over three years |
| What we did | Vulnerability assessment, fixes and retest, led by our security co-founder |
| Trigger | The hosting provider flagged unusual login attempts on the admin |
| Timeline | 5-day assessment. Fixes and retest complete in 3 weeks |
| Result | 7 of 7 closed, 2 of them critical. Clean retest. Store open throughout |
The problem ( unusual login attempts on a WordPress store )
The store had grown fast for three years. Every new need got a plugin, a snippet of custom code or another integration, and each one went live because it worked. Nobody had ever tested the whole site as one system.
Then the hosting provider flagged a run of unusual login attempts on the admin. The owner’s question was a fair one. Was this one bot rattling the front door, or was the front door the least of it?
“I assumed it was one bot hammering the login page. The report showed me two ways in that I would never have found myself.”
5 things we found in an ecommerce vulnerability assessment
The login attempts weren’t the biggest risk
The search box could talk straight to the database
The site’s code was downloadable by anyone
A .git directory had been left on the live server by an earlier deployment. Anyone who knew where to look could download the code history, including credentials stored in it. Exposed .git directory, critical.
Two smaller gaps added up to one large one
An outdated plugin let a low-level account raise its own permissions, and the admin login had no limit on attempts. Either is serious alone. Together they were a path from guessing a password to running the store. Privilege escalation and no login rate limiting, both high.
Shopper-facing features trusted input they shouldn’t have
Product reviews accepted script code that would run in other shoppers’ browsers. Error pages announced the server and database software, and the TLS setup still allowed older protocols. Each is a medium risk alone, and each one hands an attacker a clue. Stored XSS, weak TLS and information disclosure, all medium.
7 things we fixed ( website security hardening )
WHAT WE DID | WHY WE DID IT |
|---|---|
Rebuilt product search on parameterized queries | Whatever a shopper types, it can no longer change the query itself |
Removed the .git directory and rotated every credential it held | Deleting the folder closes the door. Rotating the keys makes anything already copied useless |
Updated the vulnerable plugin and set up patch management | A routine for updates stops the next outdated plugin becoming the next finding |
Added login rate limiting and CAPTCHA | Unlimited password guessing becomes a handful of attempts |
Sanitized and encoded user input across reviews and forms | Reviews display as text, never as code that runs |
Hardened the TLS configuration | Only modern protocols and ciphers between shoppers and checkout |
Replaced detailed error output with secure error handling | Errors tell shoppers something went wrong and tell attackers nothing |
3 weeks, first scan to retest
WHEN | WHAT HAPPENED |
|---|---|
Days 1 to 5 | Attack-surface mapping and reconnaissance, automated scanning, manual vulnerability and penetration testing, SSL/TLS and server review, plugin, code and access-control assessment |
Within 48 hours of each critical finding | SQL injection patched, .git directory removed, affected credentials rotated |
Weeks 2 and 3 | High and medium fixes staged, tested and deployed while the store kept taking orders |
End of week 3 | Follow-up security testing. All 7 vulnerabilities confirmed closed |
7 open to 0 in 3 weeks ( vulnerability remediation )
| AREA | BEFORE | AFTER |
|---|---|---|
| Open vulnerabilities | 7, two critical | 0, confirmed by retest |
| Product search | Injectable | Parameterized queries |
| Source code | Publicly downloadable | Removed, credentials rotated |
| Admin login | Unlimited attempts | Rate-limited, with CAPTCHA |
| Plugins | Outdated, no update routine | Patched, patch management in place |
| Product reviews | Accepted script code | Input sanitized and encoded |
| TLS | Legacy protocols allowed | Hardened configuration |
| Error pages | Showed server and database details | Generic, secure messages |
| Store during the work | 800+ orders a week | 800+ orders a week, never offline |
Why it worked
- We tested before we fixed. Locking down the login page alone would have answered the host’s email and left both critical findings open.
- We fixed in order of damage. The two critical issues were closed within two days. Everything else was staged and tested first, so the store never went down.
- We fixed causes, not just instances. Patch management and sitewide input handling mean the next plugin or the next form doesn’t reopen the same hole.
- We retested. A fix counts when a second round of testing fails to get in, not when the change is deployed.
FAQ
What’s the difference between a vulnerability assessment and a penetration test?
How long does a website security audit take?
For this store, testing took 5 business days, and fixes plus a full retest brought the whole engagement to 3 weeks. The size of the job depends on how many plugins, integrations and pieces of custom code a site has, because each one is something to test.
How do I know if my WordPress site has been hacked?
Common signs are admin users you didn’t create, pages redirecting somewhere unexpected, and warnings from your host. This store started with exactly that kind of warning: unusual login attempts. A warning tells you someone is trying. Only an assessment tells you what they could reach.
How often should an ecommerce website have a security audit?
In our experience, at least once a year and after any major change, such as a new set of plugins, a new integration or a redesign. This store had three years of changes and no assessment, which is how seven issues built up unnoticed.
