Security Policy
Security is managed as an operating discipline. This page describes the controls we use today, the limits of those controls, and how to report a concern.
1. Security Model
The platform uses layered controls rather than any single security measure. Those controls may include server-side validation, access gating, session controls, encrypted transport, environment isolation, audit logging, and least-privilege operational access.
Parts of the site are static or cache-friendly, while other parts are dynamic and stateful. We do not represent the system as invulnerable, and no internet-facing service can guarantee complete security.
2. Access And Session Controls
Access-controlled areas use a combination of server-side checks, session management, entitlement records, and short-lived continuity mechanisms. Some client-side state is stored in your browser to preserve progress, return access, or product continuity.
We avoid storing long-lived access tokens in browser storage where that can reasonably be avoided. Legacy or transitional flows may still use browser storage for non-sensitive continuity data such as progress, reminders, and return-state markers.
3. Abuse Prevention
Selected public forms and sensitive interaction points are protected by rate-limiting, request validation, bot-detection logic, and reCAPTCHA where enabled. These measures are applied according to operational risk, not necessarily on every page.
We may also use timing signals, duplicate-pattern checks, request metadata, and other abuse indicators to protect the service and reduce automated misuse.
4. Data Handling
Security-sensitive data is handled according to the operational needs of the feature. In newer decision continuity flows, email identity data may be encrypted at rest and linked to decision records through hashed lookups or controlled session links. Not every legacy surface has been migrated to that pattern yet.
Payment processing is handled entirely by Stripe. We do not store card numbers, CVVs, or full payment credentials on our servers. Stripe processes payments under its own PCI-DSS-compliant security controls.
We minimise internal access where practical, but authorised operators, service providers, and technical staff may still need limited access to investigate service issues, fulfil requests, or respond to abuse or legal obligations.
5. Your Security Responsibilities
- Protect any access links, invitation links, or paid-resource access credentials you receive.
- Do not submit unnecessary confidential, medical, or regulated financial information through general forms unless we specifically ask for it through an appropriate channel.
- Use a current browser and keep your own device and accounts secure.
- Contact us promptly if you believe your access or data may have been exposed.
6. Reporting And Response
If we become aware of a security incident, we investigate, contain, and remediate according to the nature of the event. Where required by law, we will notify affected parties or regulators.
Security Contact
Report suspected vulnerabilities or misuse to support@abrahamoflondon.org with the subject "Responsible Disclosure Report".