"Why do you need security when you have no users?"

I asked myself this too. An OWASP security audit for a service with zero users? Seems excessive. But I knew that one breach means game over. Especially for a service handling recruitment data -- a personal information leak would end the business entirely.

So I decided to lock down security before users arrived. By handing the audit to AI.

Even Solo SaaS Gets Hacked

"Who would bother hacking a small service like ours?" is a dangerous assumption. Automated bots constantly scan the internet for vulnerable services, regardless of size.

In the first week after deploying to the cloud, I checked the server logs and was stunned. Nobody had been told about the URL, yet dozens of anomalous requests per day were hitting the server. Bots automatically probing paths like /admin, /wp-login.php, and /.env.

This made it viscerally clear: security is not optional. Even with zero users, the moment a service goes live on the internet, it becomes a target.

What Is OWASP Top 10

OWASP (Open Web Application Security Project) is an open project for web application security. The "Top 10" is a list of the most common and critical security vulnerabilities, widely accepted as the industry standard.

Addressing all 10 items is significant work for a solo developer. But it was achievable because AI proposed specific remediation strategies for each item, wrote the code, and created the tests.

XSS: The Invisible Threat

XSS (Cross-Site Scripting) is an attack where malicious scripts are injected into a website. For example, inserting <script>alert('hacked')</script> into a JD input field could execute that script in another user's browser.

XSS is particularly dangerous in recruitment services. Embedding malicious code in JD or resume data can hijack the sessions of other recruiters or admins who view that data.

The defense is three layers deep:

Security middleware sets CSP headers alongside many other security headers in one go. A single middleware line applies X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, and 10+ other security headers.

Authentication & Session Security

Convince-X handles authentication via OAuth + token-based security. When a user logs in with their social account, the server issues an auth token included in all subsequent API requests.

Key security considerations:

The HttpOnly cookie setting is simple but powerful. JavaScript can't access the cookie, so even a successful XSS attack can't steal the token. This single configuration dramatically reduces the attack surface.

Rate Limiting & Brute Force

Rate limiting means restricting the number of requests within a given time period. Why? Because of brute-force attacks.

Brute-force attacks involve systematically trying passwords or tokens. Since we use Google OAuth, password brute-forcing isn't a concern. But mass requests against API endpoints remain dangerous -- they can exhaust server resources and crash the service.

You can't apply the same limits everywhere. Login gets strict limits; search gets looser ones. It's the balance between user experience and security.

414 Security Tests

Implementing security in code and verifying that it actually works are two separate problems. That's why we created 414 security tests.

These tests don't just check "does defense code exist?" -- they simulate real attack patterns. The XSS tests, for example, inject dozens of encoding bypass patterns actually used by attackers.

The interesting part: the process of writing tests uncovered real vulnerabilities. Three endpoints missing input sanitization, two routes without CSRF verification. "Writing" the tests "caught" the bugs. Security tests serve as both verification and discovery tools.

Security Is Infrastructure, Not a Feature

If you think of security as a "feature," it gets deprioritized. "Build features first, add security later" is dangerous. By the time you try to retrofit it, you need to rewrite existing code entirely.

At Convince-X, security was baked into the foundation from day one. Security middleware, input sanitization, HttpOnly cookies -- all configured before the first feature was built.

As of this writing, Convince-X has zero production security incidents. That might be because we have few users. But as long as 414 security tests pass with every deployment, we can confidently say the safety net is in place.

Security can be skipped because it's a solo SaaS? No. Being solo means you need to be more thorough. Large companies have teams to respond to breaches. For a solo founder, breach = business over. In an era when AI can run security audits for you, cost is no longer an excuse.

Security isn't a feature -- it's infrastructure. Like rebar in a building. You can't see it, but without it, everything collapses.