AnyRun runs as one application at the edge of a global content network, in front of one relational database hosted in Sydney, Australia (region ap-southeast-2). Race photos and event media live in object storage. That is the whole surface: there is no second admin application, no internal reporting stack with its own copy of the data, and no analytics warehouse holding entrant records.

The design decision everything else follows from: the application does not hold a master database key. There is no service-role credential in the web application's environment. Every read and write it makes travels as the signed-in person, and is checked by the database against that identity. An attacker who achieved full control of the application code would still be confined to what the people using it are allowed to see.

Every table holding tenant data has Row-Level Security enabled with explicit policies. A query for entries returns only the entries the caller is entitled to; there is no unfiltered read to forget a WHERE clause on.

In practice that means an organiser sees a person through their own organisation's registrations, volunteer assignments or memberships, and through nothing else. Two organisers running events on the same platform cannot see each other's entrants. A runner sees their own record, their own results, their own photo matches, their own legal acceptances.

The same boundary covers an organisation's own private details. Its payment account, its verification email and the notes we keep about it are readable by its own team and by us. Another signed-in account cannot read them, and neither can a visitor who is not signed in.

Some operations legitimately need to act above one person's own rows: finalising a payment, importing timing results, settling a sponsorship auction, exporting a start list. These run as a definer procedure: a database function that executes with elevated rights and, as its very first act, re-checks the caller's authority itself.

Each of them works the same way:

• Each one authorises itself against the caller's role in the relevant organisation: it does not trust the screen that called it, and it refuses an identity passed in as an argument.
• Execution rights are explicitly revoked from anonymous and public callers and granted only to signed-in users, so the procedure cannot be reached directly by an unauthenticated request.
• Authority checks are written to fail closed. The checks are phrased so that an unknown or absent answer is a refusal. A null reads as a no.
• They write to the audit log as part of the same transaction, so the action and its record cannot come apart.

A small number of procedures serve AnyRun's own platform administrators: the support and operations view. They are held to a stricter standard than anything else in the system:

• A second factor must have been presented at sign-in. The check requires the session to be at AAL2, and an absent or unknown assurance level is refused. An administrator with two-factor set up but signed in with a password alone is turned away from every one of these procedures.
• Aggregates only. The operations view reports counts, rates and health figures. It does not browse the user table.
• Looking up an individual requires a stated reason, and writes an audit row naming the administrator, the person looked up, and that reason. There is no way to look someone up quietly.
• The shared authority check is itself unreachable from outside; execution is revoked from public, anonymous and signed-in callers alike, so it can only be invoked by the procedures that depend on it.

Sign-in runs on our authentication provider, which stores only a slow one-way hash of your password. Neither AnyRun staff nor a database administrator can read it, and it does not reach our application in a form we could store. Password resets use single-use, expiring email links.

Two-factor authentication (TOTP) is available on every account, and mandatory for platform administration. Enrolment takes a six-digit authenticator app code, with one-time recovery codes covering a lost phone; AnyRun's own administrative procedures refuse any session that has not passed a second-factor check, regardless of password. Session cookies are HttpOnly, Secure and SameSite, so page scripts cannot read them.

Wrong two-factor codes are counted per account. Too many close that check for the account for a while. The count is enforced in the database, and every code our sign-in screens accept is checked against it. Wrong passwords are counted the same way.

Passwords are at least 12 characters, and a pass phrase works best. Every password is also checked against public lists of passwords exposed in known breaches, and one that appears on them is refused. A password already in use keeps working; the rule applies when you set or change one.

Two changes need more than a signed-in browser. Setting a password for the first time, and changing the address you sign in with, both ask you to confirm it is you. An account that has a password is asked for that password. An account that signs in with Google is sent there to confirm, and Google asks again even when you are already signed in. The confirmation covers one change. An address change then goes to both addresses, the one you have and the one you are moving to, and the account moves once both links are opened.

Staying signed in has a limit. A session ends after a set time, and sooner when the account is not used. Your account settings list every browser and app currently signed in, with the browser and system each reports, when it was last used, and the network block its address falls in. One control signs them all out and asks every remembered browser for a two-factor code again.

Transport is TLS everywhere, and the database and its backups are encrypted at rest by the managed infrastructure.

Your phone number, date of birth, home suburb and state, emergency contacts and Working With Children reference numbers are encrypted by the application with AES-256 before they are written to the database. A value that has been altered, or moved to another field or another person, fails to read.

The key is held apart from the database, so someone holding a complete copy of the database, and nothing else, holds unreadable ciphertext for these fields. Keys can be rotated without a period in which data cannot be read.

Sensitive information is shown masked wherever it is shown at all: a coordinator sees that a Working With Children check is recorded and current, with the number itself hidden.

Payments and refunds, results imports and corrections, photo-match reviews, data exports, membership and role changes, sponsorship auction events, deletion requests and platform-administrator lookups are written to an append-only audit log with the acting person, the entity touched and the timestamp.

The log is written inside the same privileged procedure that performs the action, so an action cannot succeed without leaving its record. Organisation admins can read their own organisation's log in the console at any time.

Public pages and the sign-up and password-reset routes are rate limited, with a stricter budget on the last two, and sign-up also carries a bot challenge. The access boundary in the database is what protects data, and the limits slow scraping and automated abuse.

Every image upload (event heroes, organiser logos, sponsor creative, add-on photos, volunteer documents) is checked by its actual contents before it is stored. SVG is refused for logos, and uploaded photographs have their embedded metadata removed, so a photo's GPS coordinates do not travel with it.

Media is served through routes that check the record it belongs to and who is asking. Race photos are also gated on the runner's own photo-matching consent, which is revocable at any time with immediate effect.

Responses carry a Content-Security-Policy that confines scripts, styles, fonts and network connections to our own origin plus a short, named list of services we actually use. frame-ancestors 'none' makes the site unframeable, so it cannot be wrapped in someone else's page and clickjacked; object-src 'none' and base-uri 'self' close two classic injection routes, and form-action 'self' means a successful injection still cannot post your form somewhere else.

Alongside it: Strict-Transport-Security so a browser that has seen the site once will not be downgraded to plain HTTP, X-Content-Type-Options: nosniff, a strict-origin referrer policy so other sites do not learn the full path you came from, and a permissions policy that switches off camera, microphone, geolocation and the payment API for the page entirely.

Card details are entered into and processed by our payment provider. AnyRun servers do not receive, process or store them: we record the order outcome and an opaque payment reference, and nothing else. Payment amounts are recomputed and asserted server-side at capture, so a total cannot be altered on its way through a browser.

All AnyRun mail (confirmations, results notices, password resets, organiser notifications) is sent through our infrastructure provider's email service on our own domain, with SPF and DKIM published and DMARC set to p=reject.

Receiving mail servers reject a message that claims to be from our domain and fails those checks, which makes an AnyRun-branded phishing email hard to deliver.

The primary database runs in Sydney. Event photographs and organiser uploads sit in a separate object store, in our edge provider's Oceania region, which is a placement preference and lets that provider put an object elsewhere in the Asia-Pacific region (the Privacy Policy sets out what we do about that). We handle personal information in line with the Privacy Act 1988 (Cth) and the Australian Privacy Principles: collection limited to what running an event needs, purpose-bound use, and real, working data rights.

• Data export: one click in your account settings, covering your record, entries, results, consents and legal acceptances.
• Deletion: photo-match removal is immediate and self-service; account erasure is confirmed by a person, because it is irreversible.
• Consent: recorded as its own append-only row with a timestamp and revocable from your settings.

Every third party that handles data on our behalf is named on the public sub-processor list, including any sub-processor outside Australia and what it is used for.

No facial recognition. Photo matching reads printed bib numbers, cross-checked against chip times. AnyRun runs no face recognition and holds no biometric templates.

The database is backed up daily, and the backups are encrypted at rest. Every change to the database's structure is recorded before it is applied, together with the steps that reverse it, and a change reaches the live database only through that record.

A written management system sits behind these controls. The controls themselves are summarised at /trust, and the documents are available on request: the information security policy, access control, secure development, business continuity and backup, the privacy impact assessment, and the incident response plan. Write to support@anyrun.net for the ones you need.

We welcome good-faith security research. Report anything you find to support@anyrun.net and we will acknowledge within two business days.

What we ask: test only against your own accounts and data, do not access, modify or retain other people's information, do not run denial-of-service or bulk automated scanning against the live site, and give us a reasonable window to fix an issue before publishing it. In return we will not pursue researchers who follow those rules, we will tell you what we did about it, and we will credit you if you want that.

Questions about your own data (consent, export, deletion) are answered from your account settings, or at support@anyrun.net. AnyRun is a registered Australian business name, based in South Australia. ABN 90 374 636 715.