Secure Web Development Framework

Summary

Security is built into every BeeTcore project from the first requirement to the last release. Every build addresses the OWASP Top 10, the industry’s reference list of the most critical web application security risks, currently in its 2025 edition. Development follows the secure development principles of ISO 27001 and privacy by design, as the GDPR and other data protection laws expect. The same framework applies to content management platforms and custom applications, with controls matched to each stack.

1. Scope and alignment

This framework covers the design, build, testing, and release of every platform BeeTcore delivers. It sets out the security controls applied within the delivery process described in the Development Methodology SOP, and is aligned to:

• OWASP Top 10:2025: every build addresses each category, as set out in Section 4.
• ISO 27001 principles: secure development is planned, controlled, tested, and reviewed.
• Privacy by design: personal data is protected by default, in line with the GDPR, the Nigeria Data Protection Act 2023, and other laws that apply to each client.

2. Security in every phase

• Requirements: security and compliance needs are captured with the client, and the risks specific to the project are assessed.
• Design: architecture, data flows, and access rules are designed to prevent known weaknesses before any code is written.
• Build: code and configuration follow the controls in Section 4 and Section 7.
• Test: security is tested alongside function, as set out in Section 5.
• Release: nothing reaches production without passing the security review.
• Maintain: platforms are patched, monitored, and reviewed for as long as BeeTcore looks after them.

3. Secure design principles

• Least privilege: every user, service, and integration gets only the access it needs.
• Defence in depth: several independent layers of protection, so no single failure exposes the platform.
• Secure by default: the safest settings are the starting point, and anything less is a deliberate, documented choice.
• Privacy by design: only the personal data the purpose needs is collected, and it is protected from the start.
• Fail safely: when something goes wrong, the platform denies access rather than allowing it.

4. OWASP Top 10:2025 controls

• A01. Broken Access Control: permissions are checked on the server for every request, never only in the interface. APIs authenticate every request, using OAuth 2.0, JSON Web Tokens, or scoped keys, and check access to each record. Outbound requests are restricted to approved destinations.
• A02. Security Misconfiguration: hardened default settings, debug output disabled, unused features and accounts removed, security headers applied where the platform supports them, and configuration reviewed before launch.
• A03. Software Supply Chain Failures: plugins, packages, and libraries come only from trusted sources, are vetted before use, are scanned for known vulnerabilities, and are kept at controlled versions.
• A04. Cryptographic Failures: TLS on every page and endpoint, passwords stored with strong one-way hashing, secrets kept out of code, and backups stored encrypted.
• A05. Injection: all input is validated, database queries are parameterised, and output is escaped, so user-supplied data is never run as code.
• A06. Insecure Design: threats are considered at the requirements and design stages, including how a feature could be misused, not only how it should be used.
• A07. Authentication Failures: multi-factor authentication for administrators, protection against brute-force login attempts, rate limiting on login and API endpoints, secure session handling, and strong password rules.
• A08. Software or Data Integrity Failures: code changes pass peer review before they merge, production branches are protected, and updates are installed only from verified sources.
• A09. Security Logging and Alerting Failures: security events are logged and alerts reach the responsible team member, as set out in Security Continuous Monitoring.
• A10. Mishandling of Exceptional Conditions: errors are handled safely, the platform fails closed, error messages never reveal sensitive detail, and unexpected conditions are logged.

5. Security testing

• Code review: every change to custom code is peer reviewed with security in mind before it merges.
• Static analysis: source code is scanned for vulnerabilities (custom code).
• Dependency scanning: third-party packages are checked against published vulnerabilities.
• Dynamic testing: the running application is scanned for exploitable weaknesses before release (custom code).
• Security requirements testing: access rules, encryption, and other security controls are tested to confirm they work as designed.
• Pre-release security review: every build is checked against the OWASP Top 10 before it goes live.
• Penetration testing: independent penetration testing is arranged where the project agreement requires it.

6. Environments and test data

• Development, staging, and production environments are kept separate. Staging is hidden from search engines.
• Personal data in development and testing environments is limited to what testing requires, and protected to the same standard as production. Where realistic data is needed without real records, it is anonymised or masked.

7. Secure deployment

• Server and platform configurations are hardened before launch.
• Custom applications deploy through automated pipelines that run security checks before release.
• A backup is taken before every deployment, and every release can be reversed, as set out in the Change Management Framework.
• Deployment activity is logged and reviewed for anything unexpected.

8. Third-party components and patching

• Every plugin, package, and integration is vetted for its source, maintenance history, and security record before use, and removed when it is no longer needed.
• Security advisories for components in use are monitored, and patches are tested before they are applied. Responsibility for patching by hosting model is set out in the Cloud Security Framework.
• Integration keys are stored securely and carry only the permissions they need, as set out in the Development Methodology SOP.

9. Application-layer protection

Platforms are shielded at the edge by Cloudflare’s web application firewall. WordPress platforms add application-level protection from Wordfence and MalCare. Details are set out in the Intrusion Detection or Prevention Systems and Denial of Service Detection and Mitigation Controls documents.

10. Monitoring, response, training, and compliance

• Platforms are monitored after launch, as set out in Security Continuous Monitoring.
• Security incidents follow the Incident Management Response Strategy.
• Developers are trained in secure coding, as set out in the Strategic Information Security Awareness Program.
• Client-specific security and regulatory requirements are captured at the start of each project and confirmed in the project agreement.

11. Review

This framework is reviewed annually, when OWASP publishes a new edition of the Top 10, and after any significant incident. Findings feed into Continuous Service Improvement.

Frequently asked questions