Security Basics Every Custom Software Project Needs

The Short Answer

Custom software security is not an add-on you buy at the end — it is a set of baseline decisions baked into the architecture from day one: authentication, authorization, input validation, secrets management, and audit logging. Get these right and you block 90% of common attacks. Skip them and no amount of later patching fully closes the gap.

The OWASP Baseline Every Custom App Needs

The OWASP Top 10 lists the most common web application security risks. For a custom B2B application, the five that matter most are: broken access control, cryptographic failures, injection attacks, insecure design, and misconfiguration. These are not theoretical — they are the vulnerabilities that show up in real breach reports year after year.

Authentication: Who Are You?

Passwords must be hashed, never stored in plain text. Use bcrypt or Argon2 with a per-user salt. Enforce a minimum password policy (12+ characters, not complexity theater). Add multi-factor authentication for admin accounts — this single step blocks most credential-stuffing attacks. Session tokens should expire, be stored HttpOnly and Secure, and be invalidated on logout.

Authorization: What Are You Allowed to Do?

Broken access control is the number one OWASP risk. Every API endpoint must check: is this user logged in? Does this user have permission to access this specific resource? Do not rely on hiding UI buttons — the API must enforce permissions independently. A user should never be able to access another user's data by changing an ID in the URL.

Injection Protection: Treat All Input as Hostile

SQL injection, XSS, and command injection all share one root cause: untrusted data being interpreted as code. Use parameterized queries for every database call. Escape all user-generated content before rendering it in the browser. Never concatenate user input into shell commands. These are not optional best practices — they are the minimum.

Secrets Management: Where Your Keys Live

API keys, database passwords, encryption keys, and third-party tokens should never be hard-coded in source code. They should live in environment variables or a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault). They should be rotated regularly. They should never appear in git history — if a key has been committed to a repo, treat it as compromised and rotate it immediately.

The Audit Trail You Cannot Skip

Log every significant action: who logged in, what they changed, when, and from what IP. These logs are not just for compliance — they are how you detect an incident after the fact. A security event that is never logged is a security event that is never caught. Store logs centrally, protect them from tampering, and keep them for at least 90 days.

Common Security Mistakes in Custom Projects

We will add security after launch — retrofitting security costs 3–5x more than building it in from the start, and always leaves gaps.
Relying on obscurity — nobody knows our app exists is not a security strategy. Automated scanners find exposed admin panels in hours.
Skipping input validation on the server — client-side validation is for UX. The server must re-validate every input, every time.
Using outdated dependencies — most real breaches come from known vulnerabilities in third-party libraries, not from custom code. Run dependency scans monthly.
No incident response plan — you will have an incident. The question is whether you know what to do when it happens.

Security Budget: What It Actually Costs

For a custom B2B application, building security in from day one adds roughly 15–25% to the development cost. This covers authentication systems, authorization middleware, input validation, secrets management, audit logging, and basic penetration testing. It sounds expensive until you compare it to the alternative: a single breach can cost a mid-sized company 200,000 to 500,000 dollars in response, downtime, and legal fees — before any regulatory fines.

Your Launch Security Checklist

All passwords hashed with bcrypt or Argon2.
MFA enabled for all admin accounts.
HTTPS enforced everywhere, HSTS headers set.
Security headers configured (CSP, X-Frame-Options, X-Content-Type-Options).
All API endpoints enforce authorization checks.
Database queries use parameterized statements.
Secrets stored in environment variables, not code.
Dependency scan run with no high-severity vulnerabilities.
Audit logging active for all sensitive actions.
Backup and recovery tested.

Security FAQ

Quick answers to the questions we hear most often about custom software security.

Is custom software more or less secure than off-the-shelf?

It depends entirely on how it is built. Off-the-shelf software benefits from wide usage and public scrutiny — vulnerabilities get found and fixed quickly. Custom software is less targeted by attackers simply because it is obscure, but when a vulnerability exists, there is no vendor pushing a patch. The advantage of custom software: you control the architecture and can implement exactly the security controls your business needs. The risk: if your developer skipped security basics, nobody is coming to save you.

Do we need penetration testing?

Before handling sensitive customer data or processing payments, yes. A basic penetration test for a custom web app costs 3,000 to 10,000 dollars and typically finds 5–10 real vulnerabilities that automated scanners miss. For regulated industries (healthcare, finance), this is not optional — it is a compliance requirement.

How often should we update security?

Three layers: (1) automated dependency scans monthly; (2) a security review after every major feature release; (3) a full penetration test annually or after significant architectural changes. Security is not a checkbox — it is an ongoing practice.