Security should be built in, not bolted on
Web app security is not a final checklist before launch. By the time you are doing pre-launch testing, the decisions that determine how secure your application is have already been made. The architecture, the data model, the third-party services you chose, the way authentication works - all of those were locked in months earlier. This article covers five practices we apply throughout development to keep web apps secure.
1. Encrypt all traffic
Every request between your users and your application should travel over HTTPS. This encrypts data in transit and prevents it being read if intercepted. SSL/TLS certificates are available free through most hosting providers and cloud platforms. There is no good reason to run production traffic over HTTP.
2. Encrypt sensitive data at rest, and do not store it if you do not need it
If your application stores passwords, they should be hashed using a modern algorithm such as bcrypt or Argon2, never stored as plain text or with reversible encryption. For other sensitive data such as payment information or identity documents, the first question to ask is whether you need to store it at all. Data you do not hold cannot be breached. If you do need to store it, encrypt it at the field or row level, not just at the disk level.
3. Run security scans
Automated security scanners test your running application for common vulnerabilities including injection attacks, broken authentication, and exposed sensitive data. Running these regularly, and certainly before any major release, catches issues that code review alone misses. Many are available as part of a CI-CD pipeline so the scan happens automatically on every build.
4. Run static code analysis
Static analysis tools examine your source code without running it. They identify patterns associated with known vulnerability classes: SQL injection, cross-site scripting, insecure deserialization, and others. Integrating a static analysis tool into your development workflow means these checks happen on every commit rather than as a one-off exercise.
5. Check your security headers
HTTP security headers tell browsers how to behave when loading your application. The Content-Security-Policy header restricts which resources the browser will load, reducing the attack surface for cross-site scripting. The Strict-Transport-Security header enforces HTTPS. X-Frame-Options prevents your pages being embedded in iframes on other domains. These are straightforward to configure and make a measurable difference to your application's security posture.
Security is one of the areas where the cost of fixing problems grows significantly over time. Issues caught during development are cheap to fix. Issues discovered in production are not.
Contact us to learn more about how we build security into our web app development process.
