Security and Data Practices

How this site is built and protected, what data exists to protect, how to report a vulnerability, and the security gaps we know about.

Last reviewed August 4, 2026

The strongest control is the data that does not exist

There are no accounts, no stored practice results, no payment data and no analytics. Your answers live in your browser’s memory for the length of a session and are discarded. The only thing written to your device is a theme preference.

That is a design decision rather than an unfinished state. A study site does not need to know who you are in order to be useful, and data never collected cannot be breached, subpoenaed or sold.

Transport and headers

  • All traffic is served over HTTPS, with plain HTTP redirected and HSTS set.
  • One canonical hostname; other variants redirect to it permanently, so there is no ambiguity about which origin is real.
  • A content-security policy locked to this origin, plus nosniff, a strict referrer policy, clickjacking protection and a restrictive permissions policy denying camera, microphone and geolocation.

The content-security policy permits inline scripts because the theme has to be applied before first paint, otherwise the page visibly flashes the wrong colours. It permits eval only in development, where React’s development build requires it — a test asserts that production never ships with it, so a debugging convenience cannot escape into the live site.

How the application is built

  • Pages are statically rendered. Most requests are served without executing application logic against your input at all.
  • The input surface is small and enumerated. No forms, no search, no comments and no uploads. The attempt API is the only place that accepts input: it takes a form identifier, an attempt identifier and an answer selection, each validated before use. It exposes no endpoint that accepts a question identifier, so the question bank cannot be walked through it.
  • Content is validated at build time. A malformed question fails the build rather than rendering.
  • Structured data is generated from typed inputs and serialised safely; no author-supplied markup reaches the page.
  • Errors reveal nothing. The error page shows a reference identifier, not a stack trace.
  • Dependencies are few and checked. Builds use a committed lockfile, and advisories are reviewed on a schedule.

Every API response carries a request identifier, in an x-request-id header and in the body of an error, so a report of “this failed” can be matched to a log entry without asking you for a screenshot. Ordinary pages do not carry one: they are generated once and served from a cache to everyone, so there is no per-request value to attach.

Secrets

No credentials are committed to the repository. Environment files are excluded from version control, real values live only in the deployment platform’s configuration, and an automated job checks tracked files for credential patterns. Where a secret is ever exposed, the response is to rotate it first and clean up second.

Why there is no database, and no plan to add one

An earlier version of this site was designed around accounts, saved progress and a paid plan. That design was abandoned, and the code implementing it was deleted rather than disabled: there is no authentication provider, no database client, no payment integration and no server API in this repository at all.

The consequence is the strongest privacy guarantee a website can offer, which is not having the data in the first place:

  • Your practice never leaves your browser. Attempts, answers and history are stored locally on your own device. Nothing is transmitted to us, so there is no server copy to leak, subpoena or sell.
  • There is no account to compromise. No email, no password, no profile — nothing to phish and nothing to breach.
  • No payment surface exists. The site cannot take money, so there are no card details, no billing records and no subscription state anywhere in the system.
  • You can inspect and remove everything. Export your progress as a file, or clear it, from the controls on the site. Clearing your browser storage erases every trace.

The trade-off is honest and worth stating: progress does not follow you to another device, and clearing your browser data deletes it permanently. We think that is the right exchange for a free practice site, and we would rather say so than quietly collect data to avoid it.

What an attacker could actually gain today

Worth stating plainly, because it is the honest measure of your risk in using this site.

There is no account to compromise, no stored practice history to read, no email address on file and no payment method. Someone who fully compromised this site could deface it or serve malicious content to visitors — which matters and is why the controls above exist — but they could not learn anything about you, because nothing about you is here to learn.

The realistic worst case is therefore an integrity problem rather than a confidentiality one: altered questions, or altered claims about the exam. That is part of why the question bank lives in version control with an immutable change log rather than in an editable database, and why factual claims carry a source and a verification date that a reader can check independently.

Why we are telling you the gaps

A security page listing only controls is marketing. The gaps below are real, and publishing them costs us nothing an attacker could not determine anyway — no aggregated error monitoring is inferable from behaviour, and an inline-script policy is visible in the response headers to anyone who looks.

What publishing them does buy is a commitment. A gap written down is harder to leave open indefinitely than one nobody has articulated, and it gives you something concrete to hold us to when accounts eventually ship.

Reporting a vulnerability

Please report privately through the contact page before disclosing publicly, and allow a reasonable window for a fix. Please do not degrade the service for other users, access data that is not yours, or run automated scanning at volume.

There is no paid bug-bounty programme. Reports are acknowledged and reporters credited if they want to be.

Known gaps

  • No aggregated error monitoring. Errors reach platform logs, but nothing alerts on a spike.
  • The content-security policy requires inline scripts. Justified above, but weaker than a nonce-based policy would be.
  • No automated dependency-update pipeline. Advisories surface on a schedule; applying them is manual.
  • No penetration test. Defensible while the attack surface is this small, and it stops being defensible the day accounts ship.

None of the account or payment features described above is live yet, so none of those risks currently applies to you.

Who wrote this, how it was made, and why

Who
Written by the AFOQTPracticeTest.net editorial team. We do not yet have named subject-matter reviewers with verifiable credentials attached to this site, and we will not invent them — so this page carries no expert byline. See authors and reviewers for how review works today and what we are changing.
How
The controls described are implemented in the codebase and, where testable, asserted in continuous integration — for example a test confirms the production content-security policy does not permit eval. The known gaps are our own assessment.
Why
A candidate should be able to judge the risk of using this site. The honest answer is that the risk is currently low mainly because there is almost nothing here to lose.
Last reviewed
August 4, 2026. Read our editorial policy or report an error.