A web developer's journey from building sites for Fortune 500 companies without a single security thought, to getting calls from the FBI.
In 1999, I was 22, working at Ogilvy in Washington, DC, building websites for Ford, MasterCard, and Coca-Cola.
Security wasn't on my mind. Not even a little.
These were static HTML pages — no JavaScript, no databases, nothing dynamic. The sites were insanely simple, and the servers matched. We had a file repository, uploaded HTML files, and that was it. While some people used point-and-click tools like FrontPage, we hand-coded everything in basic text editors.
We knew hacking existed. It seemed like a threat reserved for mainframes and Hollywood movies — WarGames, Hackers, that sort of thing. Even when working with major household names that would today be considered high-value targets, security simply wasn't part of the conversation.
What's remarkable, looking back, is that we were building the early commercial web completely blind to what was coming. In a hacker zine called Phrack, a researcher named Jeff Forristal had just documented something called "SQL injection" on Christmas Day 1998. He noted that Microsoft's response to his findings was essentially: "This is not a problem, so don't worry about doing anything to stop it."
Nobody worried. The industry wouldn't take SQL injection seriously for another four years.
When Databases Changed Everything
From static websites, I moved to ASP Classic, which meant connecting to Microsoft Access or Microsoft SQL Server databases. That added an entirely new layer to the stack.
Suddenly, we weren't just serving pages — we were storing information. Databases can be written to and manipulated; that's what they're designed for. For the first time, we were building what today would be considered content management systems, though back then they were mostly textarea fields that controlled bits of information on a page.
We read about SQL injection in technical articles. We saw warnings like "sanitize your queries." But this was the era of self-learning. Being told to sanitize queries meant nothing until you understood what sanitization actually did. Stack Exchange didn't exist yet. Googling "sanitized SQL queries" led to dense technical documentation with no real-world context.
Then came the summer of 2001.
In July, a worm called Code Red infected 359,000 computers in a single day, defacing websites with "Hacked by Chinese" across the screen. Researchers named it after the Mountain Dew they'd been drinking during the all-nighter spent analyzing it. A patch had been available for a month. Nobody had installed it.
Two months later — one week after September 11th — the Nimda worm became the internet's most widespread virus in 22 minutes, using five different attack vectors simultaneously. Some media speculated it was Al-Qaeda. It wasn't. It was just the future arriving ahead of schedule.
I remember hearing about these incidents. They felt distant, like news from another world. Our sites were still vulnerable. We just didn't know how vulnerable we were.
The Light Bulb Moment
Around 2004, I finally understood SQL injection. By then, I had moved from ASP Classic to ColdFusion, and the websites had grown substantially. Traffic had increased. Microsoft Access couldn't handle the load, so we switched to Microsoft SQL Server.
It was incredibly susceptible to injection.
We didn't have clean URLs back then. Our links looked like page.cfm?id=123 — long strings of variables passed directly to the database, fully visible in the browser's address bar, easy to manipulate.
I remember the article that made it click. It explained that you could append something like AND DROP ALL to a URL and delete an entire database. Taking it further, you could run INSERT and UPDATE commands to inject content. This was how Viagra ads ended up on legitimate websites — pharmaceutical spam was so common that even non-technical people recognized it.
A massive light bulb went off.
The unsettling part was that we still had unprotected applications running in production. From that day forward, we wrote sanitization rules into every SQL query. ColdFusion eventually added tags that handled sanitization automatically. We implemented validation for email addresses and phone numbers.
But none of that meant our code was truly secure. It was sobering to realize how easily a site could be compromised.
Around this time, I called a vendor about getting a firewall. The sales call stuck with me. They wanted to sell me a Barracuda appliance — a physical box you'd lease and install in front of your server. Licensing alone exceeded $1,000 per month, plus hardware costs and manual patching and maintenance.
I was running client websites from a basement server in Arlington, Virginia — a machine I could physically walk up to and touch. Spending that much on security was unthinkable.
So I didn't. None of us did.
The Wild West of Online Payments
Between 2008 and 2010, we started building online payment systems. My experience was primarily with political donations.
Stripe didn't exist. There were no turnkey solutions like ActBlue or Blue State Digital that you could simply plug in. We built payment processing from scratch.
SSL was still optional on many sites. Certificates cost hundreds of dollars annually. Let's Encrypt wouldn't launch for another six years. We were passing credit card data over connections that may or may not have been encrypted.
We never experienced a major breach during those early years. Looking back, that was pure luck.
The FBI Call
Fast forward to 2012.
I had a major national political action committee as a client — a household name in political circles, run by former members of Congress and the Senate. The donations they collected supported campaigns for some of the most powerful sitting members of Congress.
A few weeks before a major national election, they came under attack.
It was clearly targeted. Attackers flooded our donation system with stolen credit cards, charging only pennies per card. The attack served two purposes: first, to verify which stolen card numbers were still active; second, to cripple the PAC's ability to collect donations during the final stretch before the election. If valid donations couldn't be processed because we were drowning in fraudulent ones, sitting members of Congress would lose critical campaign funding at the worst possible moment.
Given who was involved, the FBI got interested.
I ended up on calls with federal agents.
During one conference call — my client, I, and two FBI agents — we walked through everything that had happened. Near the end, one agent asked a pointed question.
"So, how do you make your money?"
I told them I charge by the hour.
Silence. They realized that, aside from whoever was running the stolen credit cards, I was the only person who actually profited from this attack. Every hour I spent responding to it was billable.
Suddenly, I became the FBI's interest.
It was almost comical. My client trusted me completely and immediately vouched for me. The suspicion passed quickly. But for a brief moment, my billing model made me a person of interest in a federal investigation.
Then came the real question: "What do we do about it?"
That question haunted the entire era. Security was our responsibility. We had to figure it out ourselves.
We implemented reCAPTCHA. We deployed honeypots. We built rate limiting. We threw every defense we could think of at the problem.
There was no affordable Security-as-a-Service option. No Cloudflare plan fits our budget. Just us, improvising defenses while a sophisticated attacker tried to influence an election by strangling our fundraising.
Waiting Out the Storm
By 2010, bot attacks had become routine.
Rackspace hosted us at the time. Bots would discover one of our sites and pummel it with DDoS traffic until the server collapsed.
We paid thousands monthly for premium support, and Rackspace couldn't do much about it. They could blacklist individual IP addresses, but sophisticated attackers used rotating IP farms. There was no real defense.
Our actual strategy was to wait for the attack to end.
The server would become unresponsive or slow to a crawl. Clients would call in a panic. We'd explain that we were under attack and there was nothing to do but ride it out. Then we'd go back to work until the next assault.
I researched security services. They were prohibitively expensive — hundreds of dollars monthly for a single website. Cloudflare had launched in 2010, but its per-site pricing was equally out of reach.
We were charging clients $40 to $100 per month for hosting. We couldn't layer on security costs that exceeded the hosting fee itself. And we couldn't raise prices dramatically, because clients rarely prioritize security until something goes wrong.
So we weathered the storms and hoped for the best.
When Security Finally Became Affordable
Around 2014, pricing finally dropped enough that we could negotiate an agency deal to protect all our hosted sites.
That was a turning point.
For the first time, we could deploy a Web Application Firewall in front of every client site. We could see where attacks originated. We could watch threats get blocked in real time.
The volume of attacks was staggering — far more than we'd realized. SQL injection attempts, brute force login attacks, and bot traffic. All the threats we'd been trying to handle manually were now stopped automatically at the edge.
We used Sucuri for several years, paying between $10 and $20 per site monthly. Still significant, but finally manageable.
It wasn't until around 2022 that Cloudflare integrated with our hosting platform via Cloudways, bringing enterprise-grade protection to roughly $5 per site. With server-level security, we could finally offer comprehensive protection while keeping hosting plans between $40 and $100 per month.
The economics that had been impossible for fifteen years suddenly worked.
The New Normal
Today, major attacks rarely penetrate our defenses.
Between Cloudflare at the edge and Imunify360 on the server, our total security cost is about $8 to $10 per website per month. Malware isn't a daily concern. The protection that would have cost thousands twenty years ago now costs less than a streaming subscription.
I think about that Barracuda sales call — over $1,000 monthly for a single firewall appliance, plus hardware, plus maintenance. Today, we get better protection for a fraction of the price, with zero hardware to manage.
But there's a trade-off.
When outages occur now, I often have little control over resolution. I check status pages. I make phone calls. I communicate with clients whose sites have been down for five whole minutes.
We've exchanged the chaos of the patchwork era for dependency on a handful of massive providers. When Cloudflare experiences problems — and they've logged over 34,000 incidents since 2015 — significant portions of the internet go down at the same time. In November 2025, a Cloudflare bug simultaneously took down X, OpenAI, League of Legends, and Canva.
I no longer know which physical machine hosts my clients' sites. I know the data center region, but the specific hardware is completely abstracted. The server I once visited in that Arlington basement — the one I could point to and say "that's mine" — that concept no longer exists.
That's progress. Mostly.
What Twenty-Five Years Taught Me
In 1999, I built websites for Ford and Coca-Cola without a single thought about security.
In 2004, I learned you could delete an entire database from a URL.
In 2012, the FBI asked how I made my money.
In 2025, I pay $10 monthly for protection that once cost thousands, and I get frustrated when Cloudflare has a ten-minute outage.
The arc of web security bends toward accessibility. Tools that once required enterprise budgets are now built into basic hosting plans. Attacks that would have devastated us in 2010 are stopped automatically before reaching our servers.
But threats keep evolving. Sophistication scales. Stakes rise. The 2012 PAC attack involved credit card fraud and election interference. Today's attacks involve AI, state actors, and infrastructure we can't see.
Standing in Barnes & Noble in 2002, flipping through a ColdFusion book while my server sat offline, I was just trying to survive the day without getting fired. I didn't realize I was building the foundation for understanding a threat landscape that would define the next quarter-century of my career.
Everything I learned the hard way — the command line, injection patterns, DDoS survival tactics — enables me to solve problems faster than most people. It's what allows me to explain to clients why their site went down, where to look when something breaks, and what to do next.
These days, it's less about handling constant emergencies and more about knowing exactly what to do when one occurs.
Shane Larrabee is the founder of FatLab Web Support, a WordPress hosting and maintenance company established in 2011. He's been building websites since 1998 and has managed to avoid FBI suspicion ever since.