Security is often scheduled as a phase near the end of a project, shortly before launch and shortly after the budget has been spent. By then the architecture is fixed, the data model is in production, and the findings that matter most are the ones nobody can afford to act on.
The decisions below cost little when made during design. Each becomes substantially more expensive after a system is live.
Decide what data you will not collect
The most reliable protection for a piece of personal data is not holding it. Systems accumulate fields because someone thought they might be useful later — national identity numbers, dates of birth, full addresses, precise location history — and each one becomes an obligation.
During design, take every field and ask which business function currently depends on it. If the answer is speculative, leave it out. Adding a field later is a small task. Explaining a leak of data you never needed is not.
Design authorisation before you write features
Authentication — confirming who someone is — is usually handled reasonably well, because a broken login is immediately visible. Authorisation — what that person may do — is where problems concentrate, because the failure is invisible until someone finds it.
Check permissions on the server, every time
Hiding a button in the interface is presentation, not protection. Every request must be authorised on the server, including ones that only an administrative interface is supposed to be able to send.
Verify ownership, not just role
A frequent flaw is checking that a user is a customer, then returning whichever record identifier the request asked for. The check must confirm that this specific record belongs to this specific user. This class of issue is common, easy to introduce, and easy to prevent when it is part of the design.
Write the access model down
A short table of roles against permitted actions and data scope takes an hour to produce and gives reviewers something concrete to test against. Without it, correctness is a matter of opinion.
Keep secrets out of the repository
Database passwords, API keys and signing secrets committed to version control remain in the history after they are removed. Automated scanners search public repositories for exactly this, continuously.
- Store secrets in a managed secret store or in environment configuration held outside the codebase.
- Use different credentials for development, staging and production.
- Rotate credentials when a team member with access leaves.
- Enable secret scanning on your repository so an accidental commit is caught quickly.
- Treat any secret that has been committed as compromised and replace it, rather than only deleting the line.
Take dependencies seriously
A modern application is mostly other people's code. That is a reasonable trade, but it means your security posture includes every package you install and everything those packages install.
Enable automated dependency alerts, schedule a regular update window rather than waiting for an incident, and be conservative about adding a package for functionality that a small amount of your own code would cover. Each dependency is a permanent maintenance commitment.
Validate input on the server
Browser-side validation exists to help users correct mistakes quickly. It provides no protection, because a request can be sent directly to the endpoint without ever touching your interface.
- Validate type, length, format and range on the server for every field.
- Use parameterised queries so user input is never concatenated into a database statement.
- Encode output according to its context to prevent script injection.
- Validate uploaded files by content and size, and store them outside the web root.
- Apply rate limiting to authentication and to any endpoint that sends messages or triggers cost.
Log enough to reconstruct events
After a security event, the first question is what happened and when. Without an audit trail there is no answer, and the response becomes guesswork.
Record authentication attempts, permission changes, administrative actions and access to sensitive records — with the actor, the time and the source. Equally important, redact sensitive values from the logs themselves. A log file containing passwords or full card details is a second copy of the problem.
Test your backups
Backups are widely configured and rarely verified. An untested backup is an assumption, and the moment you discover it was wrong is the worst possible moment to discover it.
- Restore to a separate environment on a defined schedule.
- Confirm the restored data is complete and usable, not merely that the file exists.
- Record how long the restore actually took, because that is your real recovery time.
- Keep at least one copy where a compromise of production cannot reach it.
Plan the response before you need it
A small organisation does not need an elaborate incident-response programme. It does need a single page that answers a few questions: who is contacted first, who can shut down access, where the logs are, who speaks to customers, and what the notification obligations are. Deciding this calmly in advance is far better than deciding it at two in the morning.
Where this leaves you
None of the above is exotic. It is a set of ordinary engineering habits applied consistently: collect less, authorise properly, keep secrets out of code, update dependencies, validate on the server, log meaningfully, verify backups and know who to call.
If you are starting a new system, these decisions are close to free right now. If you already have one in production, a structured review will tell you which of them are missing and in what order to address them.
Related services
If this article is relevant to something you are working on, these are the services that usually apply.
Written by Ascendia Technologies Nepal. Articles here reflect our own engineering practice and the questions organisations bring to us. If something in this piece applies to your situation, we are glad to discuss it — get in touch.