A peek under the hood

Security & encryption.

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.

Stats for nerds · technical edition

Security details, without the guesswork.

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.

Encrypted connectionChecking this page…
PasswordsPBKDF2-HMAC-SHA-256 · 100,000 iterations
Login sessionsHttpOnly · Secure · SameSite=Lax
What's being protected?

Your connection

When you visit via HTTPS, TLS helps protect information travelling between your browser and the website, including forms and account requests.

Your password

The website stores a salted, computationally stretched password value—not your original password as readable text.

Your horse profiles

Server-side permission checks limit access to private horse details and photos to their owner and authorised administrators.

Your bookings

Booking management checks who is signed in; changes to someone else’s reservations are restricted unless made by an administrator.

Live browser diagnostics

What your browser can actually verify

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.

TransportChecking…From the page URL; not the negotiated TLS cipher
Secure contextChecking…Browser's isSecureContext result
Cryptography APIChecking…Browser Web Crypto API availability
Randomness self-testChecking…One local crypto.getRandomValues() call; not an audit
Connection hostChecking…Current hostname, including preview subdomains
Page originChecking…Protocol and hostname only; no URL parameters

Not 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.

Implementation reference

Protections in the application code

LayerMechanismWhy it matters
PasswordsPBKDF2-HMAC-SHA-256, 100,000 iterations, 256-bit derived output; independent cryptographically random saltSlows password guessing if stored password verifiers are exposed. Never stores the plaintext password as a normal field.
Session tokens32 random bytes from Web Crypto; SHA-256 digest stored for session lookupHigh-entropy bearer token; the raw session token is not kept in the session lookup table.
Session cookieSecure; HttpOnly; SameSite=Lax; Path=/; up to 14 daysRestricts cookie transport and JavaScript access; reduces some cross-site request risks. A stolen session is still a risk.
Mutating API requestsOrigin checked against site origin; JSON content-type required for POST and PUTReduces cross-origin writes and unexpected form-submission patterns; not a substitute for every CSRF defence.
Account permissionsServer verifies signed-in identity, owner identifiers and administrator rolesPrevents a visitor bypassing permissions merely by manipulating visible buttons.
Booking integrityCanonical UTC timestamps, local Tasmania time validation, availability checks and D1 constraintsProtects against conflicting or falsified booking times; same rider-and-horse combination limited per day.
Sign-in attemptsDatabase-backed count for a two-minute login window; maximum eight attempts before lockoutSlows repeated guesses; Cloudflare edge rules can provide additional protection.
Photo uploadsJPEG/PNG/WebP MIME and file-signature checks, upload size limit, owner-only updatesReduces malformed file and unauthorised upload risks. It is not equivalent to full malware scanning.
Response headersX-Content-Type-Options: nosniff, X-Frame-Options: DENY, strict-origin referrer policy for Worker API responsesProvides 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.

The technical details

Go a little deeper

What type of encryption does the website use?

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.

Are passwords encrypted or hashed?

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.

How is my login kept private?

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.

Can other riders see my information?

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.

What about my stored data?

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.

Do the tests guarantee security?

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.

Does HTTPS encrypt information inside the database?

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.

How long can a login session last?

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.

What does the security scan prove?

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.

A handy rule: Check that you're on the official Honeywood website and that your browser shows a secure HTTPS connection before entering account details. Never share your password or a login session token.