Security is not a separate feature
A system may appear to work while users can access data they should not see, an administrative interface remains exposed or backups cannot be restored. Security is a design, development and operational practice rather than a final stamp.
OWASP Top 10:2025 highlights broken access control, security misconfiguration, software supply-chain failures, cryptographic failures, injection, insecure design, authentication failures, software or data integrity failures, security logging and alerting failures, and mishandling of exceptional conditions. The following checklist translates these areas into practical launch questions.
1. Access control
Verify that every user can see and change only authorised data. Test roles, customer separation, administration, direct URL access, exports, status changes and API endpoints. Hiding a button is not a security control; the backend must enforce permission on every action.
2. Secure configuration
Disable production debug mode, remove default passwords, close unnecessary ports, protect administration routes, restrict CORS, configure security headers and ensure error messages do not expose stack traces or secrets.
3. Software supply chain
Review supported dependency versions, known vulnerabilities, lock files, package sources, CI/CD permissions, container images and third-party scripts. Ongoing vulnerability monitoring must be part of operations.
4. Encryption and secrets
Use HTTPS for sensitive communication, safe cookie settings and modern password hashing. Keep API keys, database credentials and private keys out of source code, logs and client bundles. Secrets should be rotatable and access-controlled.
5. Input validation and injection prevention
Validate forms, URL parameters, uploads, APIs, webhooks, imports and third-party responses on the server. Use parameterised database access, appropriate output encoding and file restrictions.
6. Authentication and sessions
Review password handling, brute-force controls, password reset, MFA for administrators, session expiry, logout, token revocation and secure cookies.
7. Secure design and business logic
Test coupon reuse, negative quantities, approval bypass, duplicate payment, invalid status transitions and double booking. These risks require business rules, transactions, idempotency and targeted tests.
8. Software and data integrity
Use protected branches, code review, trusted build artifacts, least-privilege CI/CD, versioned migrations, signed webhook verification and documented release/rollback procedures.
9. Logging, monitoring and alerting
Log authentication attempts, administrative actions, permission changes, critical data changes, integration failures and background-job errors. Do not log passwords, tokens, card data or unnecessary personal information. Critical events need alert thresholds and owners.
10. Exceptional conditions
The system should fail safely when an external API stops responding, a database connection is interrupted, duplicate webhooks arrive, storage fills or a queue fails. The aim is to prevent uncontrolled data loss and duplicate execution.
11. Privacy
Confirm what personal data is processed, why, for how long, who can access it, which processors are involved and how deletion or access requests can be handled. Data minimisation is one of the simplest security controls.
12. Backups and incident readiness
Have automated backups, retention, an isolated copy, a restoration test, escalation contacts, key-revocation plans, rollback procedures and communication templates.
13. Performance and overload
Review critical queries, uploads, rate limits, caching, background jobs and peak load. Resource exhaustion can also become a security issue.
14. Accessibility and usability
Secure processes must remain understandable and usable. WCAG 2.2 principles improve access for people with disabilities and often improve usability for everyone.
The BT Digital approach
No responsible provider can promise a “100% unhackable” system. Our objective is proportionate risk reduction through least privilege, secure defaults, tested recovery, regular updates and observable operation.
Security is not the result of one test. It is a property of the system’s complete lifecycle.
Professional background
This checklist translates the OWASP Top 10:2025 risk areas into practical development and operational checks. Accessibility recommendations align with W3C WCAG 2.2.
