Governance · Security
Security Policy
Last updated: 13/12/2025
This Security Policy sets out how we protect the Abraham of London platform and the data you choose to share with us. Security is treated as a governance issue, not a cosmetic feature.
1. Security by Design
The platform is engineered with defence-in-depth. We combine secure infrastructure, hardened application code, and conservative data practices to reduce the attack surface and limit blast radius.
Controls are implemented at multiple layers: browser, edge, application, and service integrations. New features are assessed for security impact before they ship.
2. Bot Protection & reCAPTCHA v3
Public forms are a primary attack vector. We apply a combination of behavioural and structural controls to protect them:
- Google reCAPTCHA v3 on key flows (contact, newsletter, teaser requests), evaluated on the server.
- Action-specific scoring and thresholds to distinguish human use from scripted abuse.
- Multiple honeypot fields designed to attract and silently neutralise automated submissions.
- Normal users see no intrusive challenges; suspicious traffic is quietly throttled or rejected.
3. Rate Limiting & Abuse Controls
To protect availability and prevent brute-force style abuse, the platform applies explicit rate limits:
- IP-based and email-based rate limiting across sensitive endpoints.
- Tight limits on contact, newsletter, and subscription flows (typically 3–5 attempts per 15 minutes).
- Inner Circle registration protection – dual IP-based (20 attempts per 15 minutes) and email-based (3 attempts per hour) rate limiting to prevent abuse.
- Proper HTTP
429responses withRetry-Afterguidance when limits are exceeded. - In-memory protection as standard, with a design that can extend to Redis-backed distributed limits when required.
4. Input Validation & Sanitisation
Untrusted input is treated as hostile by default. All user data passing into the system is validated, constrained, and sanitised:
- Rigorous email validation plus rejection of known disposable domains on key flows.
- Length limits and character checks for names, subjects, and free text messages.
- Systematic escaping of content used in emails and logs to reduce XSS and injection risk.
- Strong typing across the codebase (TypeScript) to reduce malformed data and logic errors.
- Cryptographic validation for Inner Circle access keys to prevent tampering and ensure integrity.
5. Technical Security Controls
The platform is deployed on modern, reputable infrastructure with hardened defaults and secure transport:
- HTTPS enforcement with modern TLS configurations.
- Strict security headers, including HSTS, X-Frame-Options, X-Content-Type-Options, basic XSS protections, and referrer controls.
- Cross-origin isolation and restrictive cross-origin resource loading where supported.
- Controlled access to deployment, environment variables, and administration consoles.
- Hosting and email services provided by established vendors (Netlify, Vercel, Resend, Mailchimp and similar) with their own security baselines and certifications.
6. Data Minimisation & Privacy
The most robust way to protect data is not to collect it in the first place. The platform is intentionally lean:
- Only information strictly necessary to respond to your request or deliver a resource is requested.
- No public user accounts, passwords, or payment card data are stored on this site.
- Inner Circle privacy protection – email addresses are stored as SHA-256 hashes, access keys are stored as cryptographic hashes, and no raw personal data is retained in accessible formats.
- Security logs use anonymised IPs wherever possible, balancing monitoring with privacy.
- Data is retained only for as long as needed for the purpose for which it was collected.
7. Email & Communications Security
Email is handled via specialist providers with encryption in transit and established compliance frameworks:
- Resend for transactional emails (contact acknowledgements, teaser delivery, internal notifications).
- Mailchimp for newsletter and campaign delivery, with unsubscribe support and GDPR-aware processing.
- Inner Circle cryptographic key delivery – secure email transmission of access keys with minimal data exposure.
- Subscription flows are designed to prevent silent enrolment and to respect user choice.
- Email APIs are called over HTTPS with appropriate authentication and minimal payloads.
8. Security Monitoring & Audit Logging
Security events are logged with enough context to investigate issues while avoiding unnecessary personal data:
- Logging of key API activity (newsletter, subscriptions, contact, teaser requests) with anonymised identifiers.
- reCAPTCHA scores and reasons captured for security tuning and anomaly detection.
- Rate limit breaches and honeypot triggers recorded as potential abuse indicators.
- Inner Circle access monitoring – cryptographic key usage tracking without storing raw keys or personal data.
- Logs are used for operational security and troubleshooting, not for profiling ordinary users.
9. Incident Response
If a security incident is suspected or confirmed, the response is structured and proportionate:
- Rapid triage to confirm scope and impact.
- Containment and remediation of the underlying cause (for example, configuration fixes or dependency updates).
- Direct communication with affected parties where the impact warrants it.
- Regulatory notifications where required by applicable law, depending on jurisdiction and severity.
- Post-incident review to harden controls and prevent recurrence.
10. Your Security Responsibilities
Some risks sit outside any website's control. You can help protect yourself and your information by:
- Not sending highly sensitive information (for example, full financial or medical details) through standard contact forms.
- Treating unexpected requests for money, credentials, or confidential data with scepticism, even if they appear to come from this brand.
- Protecting Inner Circle access keys – treating cryptographic keys as sensitive credentials and not sharing them publicly.
- Using up-to-date browsers and operating systems with security features enabled.
- Reporting suspicious emails or activity to Abraham@AbrahamofLondon.com.
- Protecting your email account with strong passwords and, where possible, multi-factor authentication.
11. Continuous Security Improvement
Security is an ongoing discipline, not a single project. The platform's controls are refined over time as threats and standards evolve:
- Regular dependency and platform upgrades.
- Monitoring of relevant security advisories and industry guidance.
- Progressive hardening of headers, rate limits, logging, and bot detection based on observed behaviour.
- Cryptographic algorithm review – periodic assessment of hashing and key generation methods.
- Periodic review of this Security Policy to ensure it accurately reflects what is implemented.
Where this policy is updated, the revised version will be published on this page with an updated date. Material changes that affect how your data is handled will be highlighted in plain language.
For a full view of how we manage data, security, accessibility, and platform use, please refer to the following documents:
If you have questions about these policies, you can contact us or email info@abrahamoflondon.org.
These documents collectively describe our governance framework. They are for general information only and do not constitute legal, financial, or professional advice. Your use of this site remains subject to the most recent versions published here.