Security from day one: the minimum every small product needs
Security isn't a feature you add later. A few simple decisions at the start — validating input, handling passwords and keys properly, least privilege and security headers — prevent most common incidents.
"We're small; nobody will come after us." I hear that often. But most attacks aren't targeted. They are automated. Bots scan the internet for known weaknesses and don't care whether your site is large or small.
The good news is that most common incidents can be prevented with a few simple decisions at the start.
Why "later" doesn't work
Security is like plumbing in a building. In the plans from the beginning, it is cheap. Remembered after the tiling, it means breaking walls.
Some security decisions are structural: where identity is checked, how each user's data is separated, where keys are kept. Those can't be "added" afterwards.
The essential minimum
1. Trust no input
Anything from outside is suspect: forms, URLs, files, headers. Validation must happen on the server. Checks in the browser are a convenience and are easily bypassed.
The same goes for files. In this site's admin area, an uploaded image is never stored as received; it is re-encoded, so a file that isn't really an image is rejected and metadata such as location is stripped.
2. Store passwords properly
- A password is never stored in plain form — only the output of a slow, password-specific hashing function.
- The admin area requires a second factor.
- Failed attempts are limited.
- The error message doesn't reveal which part was wrong.
3. Keep keys out of the code
Service keys, database passwords and tokens never go into the repository. They live in environment variables or a secret manager, and an automated scan stops them slipping in by mistake.
4. Least privilege
Each part gets only the access it needs:
- The application runs as a limited user, not as an administrator.
- The database isn't reachable from the internet.
- Each service has its own key with limited scope.
5. Check access on every request
One of the most common weaknesses in web applications is this: the user is logged in, but by changing an id in the URL they see another user's data. "Is this user allowed to see this item?" must be checked on every request, on the server. In SaaS products that is the subject of tenant isolation.
6. Security headers
A few headers close off a large class of attacks:
- Content Security Policy (CSP): decides which scripts may run.
- Enforced secure connections.
- Blocking the page from being framed by another site.
7. Rate limiting
Without limits, a bot can submit your form or guess a password thousands of times a minute. Every sensitive endpoint needs a limit: login, sign-up, contact form.
8. Keep dependencies current
A large part of any product's code is libraries written by others. Lock versions and check automatically for known vulnerabilities.
Privacy is security too
- Collect less. Data you don't hold can't leak.
- Set a retention period. Old data that is no longer needed is deleted.
- Keep it out of logs. A user's phone number and email shouldn't appear there.
- Be honest. Tell users what you collect and why.
That is why this site works without tracking cookies and keeps a visitor's IP address only in hashed form.
Be ready for the day it goes wrong
No system is completely secure. Being ready means:
- Regular backups and, more importantly, tested restores. A backup never restored isn't a backup.
- Logging sensitive events: logins, permission changes, changes to important data.
- A kill switch: a way to disable one part quickly without taking the whole product down.
- A key rotation plan: if a key leaks, you know how to replace it.
AI products
If your product includes a language model, it has a new attack surface. A user can use text to push the model into unintended behaviour. The model's instructions are not a security wall; tool access must be limited and sensitive actions validated outside the model. More in AI agent vs chatbot.
A short pre-launch checklist
- All input validated on the server
- Passwords hashed, second factor for admin
- No keys in the code
- Access checked on every request
- Enforced HTTPS and security headers
- Rate limits on sensitive endpoints
- Backups and a tested restore
- Logs free of personal data
The takeaway
Perfect security doesn't exist, but carelessness isn't compulsory. A few sound decisions at the start turn your product from an easy target into a troublesome one, and most automated attacks stop right there.
Related: technical debt: when to take it on.