Working principles
Access follows the written scope, least privilege, and a named owner. Public content and inquiry routes remain outside any future payment middleware.
- Read-only before write
- Sandbox before production
- Reversible before irreversible
- No secrets in source, notes, screenshots, or logs
- Explicit confirmation for consequential actions
- Idempotency and audit records for outward writes
Client access
Credentials should be granted through the provider’s normal authorization flow, restricted to the exact project need, and revoked or removed at the agreed handoff.
Do not send passwords, private keys, tokens, health records, customer data, or confidential source material through the public inquiry form.
Site controls
The inquiry path uses server validation, a honeypot, request-size limits, rate limits, origin checks, and a submission identifier. Delivery credentials are runtime environment variables and are not committed to source.
The production launch gate includes a secret scan, security-header review, dependency audit, contact-delivery test, and real-domain verification. These controls reduce risk; they are not a security certification.
Report a security concern
Send a concise description, affected URL, reproduction steps, and potential impact. Do not include active credentials or unrelated personal data. Allow a reasonable remediation period before public disclosure.
Current limits
The local build emits a nonce-based content security policy and process-local rate controls. Real-domain enforcement, contact delivery, and shared rate limiting remain unverified until the Railway service and runtime variables exist.
Use one application instance until a shared rate and idempotency store is configured. Do not interpret a successful local build as a completed production security review.