74,000 Customer Records Exposed on a Live Business Website — In One Day

The Client

A multi-location retail and repair business in California with approximately 30 employees. They run an in-house extranet application that has been built and extended over 20 years. The system manages customers, employees, inventory, payments, and scheduling — it is the operational backbone of the business.

The application was built in PHP with Go microservices added over time, running on a Linux server with a MariaDB database.

What They Asked For

The client wanted an assessment of their legacy codebase to understand security risks and plan a modernisation. They knew the system was old. They did not know what was exposed.

What We Found

Day 1 — Codebase Assessment

We started with the source code. The numbers told the story before we opened a single file:

• 2,548 PHP files, 4 Go microservices, 52 scheduled jobs, 108 database migrations
• PHP 7.4 — end of life since November 2022. No security patches for over a year.
• Zero automated tests. No unit tests, no integration tests, no CI/CD pipeline.
• SQL injection throughout. Only 12 prepared statements across 2,548 files. Nearly every database query was built by concatenating user input directly into SQL.
• Evidence of prior compromise. System logs contained cleanup commands for a cryptocurrency miner. The server had been hacked before — and nobody was sure it had been fully cleaned up.
• Massive technical debt. 1,200+ duplicate and backup files. A single dashboard file of 113KB. Abandoned libraries copied three times into different directories.

This was concerning. But the codebase assessment only tells you what could go wrong. On day 2, we found out what was going wrong — right now, in production.

Day 2 — Security Assessment (Live Testing)

Every finding below was discovered on the live production system. All testing was read-only — we never modified any data.

A single URL that could read the entire database — no login required.

One endpoint accepted a table name as a URL parameter and returned all rows. No authentication check. No input validation. We accessed 197 database tables containing:

• 74,678 customer records (names, addresses, phone numbers, email addresses, dates of birth)
• Employee records including pay rates
• Credit card last-4 digits
• The most recent customer record had been created the previous afternoon

SQL injection on the payment system.

A single modified URL returned every payment transaction in the database, including that day's. We reconstructed the previous day's revenue by store location: $17,129 across 40 invoices at 4 locations. The data included customer names, transaction amounts, payment methods, and timestamps.

90,000+ customer email addresses in public files.

Two CSV files sitting in a publicly accessible directory. No login required. Just a direct URL.

The database password on a public web page.

A debug page left in production displayed the database connection credentials to anyone who visited it.

254 scanned documents downloadable without login.

A public directory contained scanned invoices showing customer names, home addresses, full credit card numbers, and handwritten signatures. Accessible to anyone with the URL.

An open email relay.

The server's email configuration allowed anyone to send emails appearing to come from the company's domain. A phishing attack waiting to happen.

5 hardcoded passwords in source code.

Including the JWT secret used for authentication tokens. Anyone with access to the source code (or a backup file left in a public directory) could forge login sessions as any user.

All 27 employees' personal data accessible without login.

Names, addresses, phone numbers, email addresses, pay rates, emergency contacts — all queryable through the same unauthenticated endpoint.

The Report We Delivered

• 12 critical findings, each documented with live proof — tables of real data, exact URLs, screenshots
• Prioritised remediation: 5 things to do today (block the worst endpoints), 5 things to do this week (credential rotation, directory access), 5 things to address as part of a rebuild
• CCPA compliance exposure analysis: California's Consumer Privacy Act provides for statutory damages of $100–$750 per consumer per incident. With 74,000+ consumer records exposed, the potential liability was significant.
• Plain English throughout. The CEO read and understood the report without help from the IT team. Every finding explained what was exposed, why it matters, and exactly how to fix it.

What Happened Next

• Critical endpoints blocked within hours. The most dangerous URLs were taken offline the same day the report was delivered.
• Credential rotation completed within days. Database passwords, API keys, and the JWT secret were all changed.
• Assessment directly informed a modernisation plan. The findings provided the evidence needed to justify investment in a complete rebuild, with security requirements baked in from the start.

The Comparison

---

Client details anonymised. All data accessed during testing was handled as confidential. Report evidence was redacted — names reduced to initials, credentials replaced with placeholders. Working data was securely deleted after the engagement.