Security and Data Practices

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

Last reviewed August 5, 2026

The strongest control is the data that does not exist

There are no accounts, no stored practice results on any server of ours, and no payment data. Analytics is limited to page-view counting, described in the privacy policy, and it stores nothing at all on the devices of readers in the UK, the EEA and Switzerland. Your answers are held by your own browser and never transmitted.

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.
  • There is no server-side input surface at all. No forms, no search, no comments, no uploads and — since the site became free with no accounts — no API. The application has zero route handlers, which is enforced by a test rather than left to memory: nothing this site serves accepts input over the network. The one thing that does read data you supply is the progress importer, which runs entirely in your browser and validates the file against a schema before touching what is stored.
  • 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. Production builds show a generic failure page. There is no stack trace, no file path and no framework version in what a visitor sees.
  • Dependencies are few and checked. Builds use a committed lockfile, and advisories are reviewed on a schedule.

An earlier version of this page said that every response carries a request identifier for matching a report to a log entry. It did not, and now there is no request to identify: every page is generated at build time and served from a cache. If something fails for you, tell us what you were doing and on which page — there is no reference number for you to quote, and we would rather say so than print one that means nothing.

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. Editorial pages like this one carry no individual byline; the practice questions are separately reviewed by a named person, whose credentials and the exact scope of his sign-off are on authors and reviewers.
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 5, 2026. Read our editorial policy or report an error.