Security is not an add-on bolted on at the end of a project, but a habit present at every stage of development. A data breach doesn't just cause financial loss; it erodes customer trust and can carry legal consequences under personal data protection regulations. Here is the practical checklist we use before a web application is released.
Authentication and access
- Passwords are hashed with a modern algorithm (bcrypt/argon2), never stored as plain text.
- Password policy and login attempt limits (rate limiting) to prevent mass password guessing.
- Two-factor authentication (2FA) for admin accounts and sensitive users.
- Role-based authorization. Every endpoint checks permissions on the server; don't just hide buttons in the interface.
Data and input
- Validate and sanitize all input on the server side. Use parameterized queries/ORM to shut down SQL injection.
- Escape output to prevent XSS, and apply a Content Security Policy where possible.
- CSRF protection on forms and requests that change data.
- Safe file uploads. Restrict type and size, rename files, and store them outside executable folders.
Transport and configuration
- HTTPS everywhere with a valid certificate, HTTP redirects, and HSTS headers. See the SSL installation tutorial.
- Debug mode off in production and secret config files (
.env) kept outside public folders. API keys never go into the repository.
Operations
- Automated backups and tested restores. A backup that has never been restore-tested is just hope. Keep a copy in a separate location.
- Dependency updates and monitoring. Schedule framework and library updates, enable logging, and set up alerts for suspicious activity.
Summary table
| Area | Risk if ignored | Quick action |
|---|---|---|
| Passwords & login | Account takeover | Hashing, rate limiting, 2FA |
| Input | SQL injection, XSS | Server validation, ORM, escaping |
| Transport | Data interception | HTTPS + HSTS |
| Configuration | Credential leaks | Private .env, debug off |
| Backup | Permanent data loss | Daily backup + restore test |
| Dependencies | Exploitation of old vulnerabilities | Scheduled updates |
Test before an attacker does
- Run automated vulnerability scans and review the results.
- Do a security-focused code review of authentication, payment, and file upload features.
- Consider penetration testing for apps that process sensitive data or financial transactions.
- Prepare an incident response plan: who to contact, how to stop the leak, and how to notify users.
Security culture in the team
The biggest gaps are often not in the code but in habits: shared passwords, old developer access that was never revoked, or credentials sent over chat. Apply the least privilege principle, revoke access when team members change, and use a password manager. Document these procedures so they stay consistent rather than relying on one person's memory.
Security after launch
Threats keep evolving. Our Maintenance package includes security patches, monitoring, and monthly reports so your application stays protected without burdening your internal team.
Want your application reviewed? Contact our team for an initial security audit.