Scripts and styles are restricted to Britain for Christ's own origin. Inline executable scripts, inline event handlers, frames and plug-in objects are blocked.
CYBERSECURITY · RESILIENCE · RESPONSIBLE REPORTING
Website security is part of protecting people and preserving trust
Britain for Christ uses a deliberately small technical attack surface, browser security controls, Cloudflare edge protection and clean recovery releases. No public website can be promised to be unhackable, so the goal is layered protection, early detection and reliable recovery.
Version 27 hardening
Protection built into the website
These controls reduce common browser-side and content-injection risks while keeping the site accessible and lightweight.
The site tells browsers not to allow Britain for Christ pages to be framed by another website.
Camera, microphone, location, payment and other unnecessary browser capabilities are disabled by policy.
The current public site does not provide visitor login accounts or expose an administrative login interface.
Britain for Christ does not directly collect or process payment-card details through this website.
Each website release can be retained as a clean deployment package with SHA-256 file checksums for integrity checking and rapid recovery.
Current form model
Minimal server-side data exposure
Current enquiry, prayer, testimony and directory-correction forms are designed to open the visitor's own email application rather than submit sensitive form content into a public website database. This reduces the amount of personal data stored by the website itself.
Future features such as accounts, uploads, online donations, comments or server-side forms must receive a separate security review before they are enabled.
Report a security concern
If you find a suspicious redirect, altered page, malicious script warning, impersonation link, exposed secret, broken HTTPS behaviour or another possible vulnerability, please report it privately.
Please do not send passwords, API keys or other secrets by email. Britain for Christ does not currently operate a paid bug-bounty programme.
Layered protection
Website code is only one security layer
Cloudflare account security
Use a unique password, phishing-resistant 2FA where possible and protected recovery codes.
DNS integrity
DNSSEC should be enabled and confirmed so DNS responses can be authenticated.
HTTPS & TLS
All visitors should be redirected to HTTPS. HSTS should only be enabled after HTTPS is fully verified and its operational consequences are understood.
WAF & bot protection
Cloudflare managed security rules and appropriate bot protection should sit in front of the public site.
Secrets never in website files
Passwords, API tokens, private keys and recovery codes must never be placed inside HTML, JavaScript, public ZIP files or source-controlled public assets.
Clean recovery
If compromise is suspected, rotate affected credentials first, preserve evidence, then restore from a known-good release rather than editing a potentially compromised copy in place.
Responsible disclosure
Security reports should be handled privately
Do not publish exploit details, credentials or personal data while a problem is unresolved. A security report should contain the affected page, what happened, how it can be reproduced safely and screenshots where useful.