Your connection
When you visit via HTTPS, TLS helps protect information travelling between your browser and the website, including forms and account requests.
A deeper look at the security mechanisms behind your connection, account, bookings and horse information. Real technical specifications, with a clear distinction between verified facts and browser-only checks.
Review the implementation details documented in the Honeywood Worker, alongside diagnostics this browser can verify right now. These are not a live penetration test or a claim of perfect security.
When you visit via HTTPS, TLS helps protect information travelling between your browser and the website, including forms and account requests.
The website stores a salted, computationally stretched password value—not your original password as readable text.
Server-side permission checks limit access to private horse details and photos to their owner and authorised administrators.
Booking management checks who is signed in; changes to someone else’s reservations are restricted unless made by an administrator.
Calculated in this browser when the page opens. No diagnostic data is sent to Honeywood by this panel, and no account, IP address, cookies or tokens are displayed.
isSecureContext resultcrypto.getRandomValues() call; not an auditNot available to website JavaScript: exact TLS version, cipher suite, certificate chain, server-to-database encryption, Cloudflare firewall configuration and whether a particular visitor's session is safe. Consult browser connection details and Cloudflare configuration for those.
| Layer | Mechanism | Why it matters |
|---|---|---|
| Passwords | PBKDF2-HMAC-SHA-256, 100,000 iterations, 256-bit derived output; independent cryptographically random salt | Slows password guessing if stored password verifiers are exposed. Never stores the plaintext password as a normal field. |
| Session tokens | 32 random bytes from Web Crypto; SHA-256 digest stored for session lookup | High-entropy bearer token; the raw session token is not kept in the session lookup table. |
| Session cookie | Secure; HttpOnly; SameSite=Lax; Path=/; up to 14 days | Restricts cookie transport and JavaScript access; reduces some cross-site request risks. A stolen session is still a risk. |
| Mutating API requests | Origin checked against site origin; JSON content-type required for POST and PUT | Reduces cross-origin writes and unexpected form-submission patterns; not a substitute for every CSRF defence. |
| Account permissions | Server verifies signed-in identity, owner identifiers and administrator roles | Prevents a visitor bypassing permissions merely by manipulating visible buttons. |
| Booking integrity | Canonical UTC timestamps, local Tasmania time validation, availability checks and D1 constraints | Protects against conflicting or falsified booking times; same rider-and-horse combination limited per day. |
| Sign-in attempts | Database-backed count for a two-minute login window; maximum eight attempts before lockout | Slows repeated guesses; Cloudflare edge rules can provide additional protection. |
| Photo uploads | JPEG/PNG/WebP MIME and file-signature checks, upload size limit, owner-only updates | Reduces malformed file and unauthorised upload risks. It is not equivalent to full malware scanning. |
| Response headers | X-Content-Type-Options: nosniff, X-Frame-Options: DENY, strict-origin referrer policy for Worker API responses | Provides defence in depth for applicable responses. Static asset headers may differ. |
Specifications above were checked against the Honeywood Worker code supplied for this project. Operational protections can change independently; this page does not monitor deployment settings.
For a normal HTTPS visit, your browser and Cloudflare negotiate a TLS connection. The exact TLS version and cipher suite depend on that connection and cannot be reliably displayed by ordinary page JavaScript.
To inspect them, use your browser's connection/security information or developer tools. We intentionally don't display a made-up cipher name.
Hashed, which is different from reversible encryption. The Worker code derives a 256-bit value using PBKDF2 with SHA-256, a separate random salt, and 100,000 iterations. That derived value is used to verify a login.
Because passwords are not intended to be recoverable from the stored value, support staff cannot simply read your password.
After signing in, the site generates an unpredictable session token. The browser receives it in a cookie with Secure, HttpOnly and SameSite=Lax settings; a SHA-256 digest of the token is stored server-side.
Secure limits sending the cookie to HTTPS connections, while HttpOnly prevents normal page scripts from reading it. SameSite helps reduce some cross-site request risks.
Private endpoints require an account, and the Worker checks account ownership for horse profiles, horse photos, notifications and rider-managed bookings. Admin functions have separate role checks.
These safeguards operate on the server—not just by hiding buttons in your browser.
The website uses Cloudflare D1 for account and booking records. Transport security, password hashing, and server-side access controls are confirmed in the application code.
Storage encryption details depend on the Cloudflare service configuration and are not directly verifiable from this page, so we don't claim a particular at-rest algorithm here.
No website can promise that. The site's code has automated tests for important behaviours and has passed a SonarQube quality gate, but automated tests and code scanning do not discover every possible vulnerability. Security also depends on configuration, ongoing updates and careful administration.
No. HTTPS/TLS protects data travelling between the browser and Cloudflare. Database storage encryption is a separate question. This page does not have independent access to D1's current encryption-at-rest configuration or keys.
The current Worker sets a session expiry and cookie lifetime of 14 days. Password changes invalidate other sessions for that account; logout deletes the current server-side session. Shared devices should always be logged out of.
The local SonarQube Community Build scan reported zero open findings and a passing quality gate with 84.1% new-code coverage at the latest reported milestone. This is a historical development-test result, not continuously updated security certification. That edition does not provide comprehensive SQL-injection or cross-site-scripting analysis.