Security policy · version 1.1
Security and incident response
Security reports are welcome when they protect visitors and stay within this website. This page publishes safe operational information without publishing credentials, defensive secrets, private reports, or instructions that would make the site easier to attack.
Current public security posture
- HTTPS delivery through Cloudflare, restrictive browser headers, no framing, no public development hostname, and no public Worker preview URL.
- Same-origin JSON checks, bounded request bodies, output limits, human verification where configured, and both per-location and site-wide rate limits for interactive services.
- Secure, HttpOnly, SameSite administrative and chat-session cookies; no credential is stored in public JavaScript or a public release archive.
- Two named administrative roles, versioned configuration, bounded audit records for account-state changes, owner-only authority for Andrew's account controls, and feature kill switches. Andrew remains revocable unless Christopher deliberately uses the separately confirmed one-way protection control; protection preserves the Corrections Management role while removing ordinary website unprotect and deactivation paths.
- Worker invocation logging disabled for this project; no application chat-transcript database; aggregate safety counts contain no message text or visitor identifier.
Good-faith vulnerability reporting
Use the Corrections Management human form, choose Privacy or safety concern, and begin the subject with Security report. Include the affected URL, date and time, browser or tool, expected result, observed result, minimal reproduction steps, and a non-sensitive proof. Do not paste credentials, private user data, live session cookies, exploit payloads that reveal personal information, or another person’s report.
In scope
https://advocatenotadversary.comand the same-origin public or administrative routes delivered for that hostname.- Authentication, authorization, access control, cross-site request protections, injection, exposed private data, unsafe public assets, and bypasses of the site’s server-enforced safety or feature-state controls.
Not authorized
- Testing another domain, provider account, mailbox, Cloudflare account, Etsy, beehiiv, Groq, NVIDIA, TikTok, YouTube, 988, or any system not owned by this site.
- Denial of service, traffic flooding, destructive testing, deleting or changing data, persistence, phishing, social engineering, credential guessing, physical intrusion, accessing another person’s record, or contacting visitors.
- Downloading more data than minimally necessary to demonstrate a finding, publicly disclosing an unresolved issue, or demanding payment. No bug bounty or payment is promised.
If a test unexpectedly exposes personal information or a credential, stop, do not retain or redistribute it, record only the minimum non-sensitive evidence, and report the event. A report does not authorize conduct prohibited by law or by a third party’s rules.
Incident severity
| Level | Example | First response |
|---|---|---|
| Critical | Active account takeover, exposed credential, ongoing disclosure of private tickets, or an AI safety failure creating imminent risk. | Disable the affected feature, preserve evidence, protect people, and notify Christopher immediately. |
| High | Unauthorized access path, material provider breach, stored injection, or repeatable safety-control bypass. | Contain access, assess data and users affected, fix or isolate, and begin notification analysis. |
| Moderate | Limited misconfiguration, non-sensitive information exposure, accessibility barrier blocking a key task, or misleading policy-to-code mismatch. | Document, prioritize, correct, test, and update the affected notice. |
| Low | Hardening suggestion or issue with no demonstrated confidentiality, integrity, availability, safety, or access impact. | Record and review during normal maintenance. |
Incident lifecycle
- Receive and preserve: timestamp the report, restrict access, preserve useful evidence, and avoid destroying logs or records needed for investigation.
- Triage: identify affected feature, data, people, providers, time range, severity, and whether the report is continuing.
- Contain: use the narrowest effective measure—feature disable, session invalidation, access restriction, provider escalation, or content removal—without changing unrelated credentials or systems.
- Investigate and remediate: determine cause and scope, fix it, test the fix, and check for the same pattern elsewhere in this website.
- Notification analysis: Christopher obtains qualified legal guidance for applicable federal, state, health-data, consumer, provider, contractual, law-enforcement, and individual notice duties. Communications must be accurate and must not create additional risk.
- Recover: restore only after validation, monitor for recurrence, and keep a rollback path.
- Learn: record decisions, update tests and policies, publish a plain-language correction or incident notice when appropriate, and track any remaining action.
Roles and authority
Christopher is the incident decision owner. Andrew may triage, contain within approved website controls, prepare fixes, preserve technical evidence, and maintain corrections. A provider handles its own infrastructure response. Qualified counsel determines legal notification advice; qualified safety, clinical, or accessibility reviewers advise only within their scope. Chris AI has no incident authority.
Reference frameworks
This policy is informed by the NIST Cybersecurity Framework 2.0, NIST SP 800-61 Revision 3, the FTC’s Data Breach Response guide, and CISA’s vulnerability-disclosure guidance. These voluntary references do not certify the implementation.
Document owner: Christopher M. Caballero · Maintenance: Andrew, Corrections Management · Version 1.1 · Effective September 5, 2026