॥ ॐ ॥   Sringeri-trained · Independent Vedic priest · Serving America since 1996(860) 759-9175 · venusaroja@yahoo.com
Security by default

A small public site can still follow serious security discipline.

The build minimizes data collection, avoids unnecessary accounts and databases, and ships deployment headers that reduce common browser attack surfaces.

Security posture: current production engineering controls are implemented in source but require correct production deployment and external verification. No claim of absolute security is made.

Security baseline

The implementation is designed with the OWASP Top 10:2025 and OWASP Application Security Verification Standard 5.0 as reference baselines. The public website minimizes attack surface by remaining mostly static; state-changing ceremony/testimonial operations are isolated behind same-origin server-side endpoints.

Form security

Production ceremony and testimonial submissions require server-side schema validation, a permitted request origin, JSON request format, Cloudflare Turnstile server-side verification, an invisible honeypot, elapsed-time checks, privacy-hashed rate limits and idempotency/duplicate controls. The anti-bot system intentionally fails closed when its production secret is not configured.

Data and injection protection

Inputs are length-bounded and normalized on the server. D1 database operations use prepared statements with bound parameters. Public responses return controlled error messages rather than internal stack traces. The public confirmation API returns only minimum confirmed-event fields.

Secrets

Deployment secrets belong in the hosting provider's secret/environment store. .env.example contains variable names only. Turnstile secret keys, email API keys and rate-limit salts must never be shipped in browser JavaScript or committed to the public site.

Headers and browser policy

The package includes a deployment header policy for HTTPS/HSTS, nosniff, referrer policy, anti-framing, permissions policy and Content Security Policy. The CSP allowlist is intentionally narrow and contains only the origins required for the current architecture. These headers must be verified against the actual deployed responses; a configuration file alone does not prove they are active.

Administrative operations

current production does not expose a public admin portal. This intentionally avoids creating an authentication surface before one is justified. Confirmation and moderation operations are documented for authorized infrastructure/database administration. If an admin UI is later introduced, it should be protected with strong identity, MFA, server-side authorization, least privilege and audit logging rather than a hidden URL or client-side check.

Logging and privacy

Security monitoring should record operational events, failure categories and request references without copying family notes, birth information or other sensitive content into analytics. Application-level rate limiting stores salted hashes rather than raw IP addresses.

Supply chain

The production dependency surface is intentionally small. Astronomy Engine is version pinned and MIT licensed. Turnstile and optional transactional email are external services. Dependency versions and third-party origins should be reviewed during each release; unnecessary third-party scripts should not be added.

Infrastructure

Recommended deployment uses HTTPS, managed edge protection/WAF, DDoS mitigation, separate preview/production configuration, restricted database bindings, account MFA, secure DNS, backups and monitoring. HSTS preload should be considered only after the owner confirms every required subdomain is permanently HTTPS-ready.

Responsible disclosure

The package includes a /.well-known/security.txt location. Before launch, replace any placeholder security contact with a monitored domain-based address and define who is responsible for triage and remediation.

Not a penetration-test certificate

Static analysis and unit tests cannot prove the deployed site is secure. Before launch, verify TLS, HTTP headers, Turnstile Siteverify, D1 bindings, rate limiting, error behavior, WAF rules and secrets on the real production hostname. Destructive testing should be performed only with authorization.