What the test version revealed

A new portal for the Czech business register was running as a public test. While examining it, Czech Radio’s iROZHLAS.cz found that the system’s technical response contained national identity numbers and AIFO identifiers for people listed in connection with companies and other legal entities. Reporters also verified that changing a document’s numeric identifier could expose some records that were not meant to be public. This was not merely a theoretical warning about a possible flaw. Source: iROZHLAS.cz’s independent testing

A national identity number is sensitive personal information. AIFO is an identifier used to distinguish people when public authorities process and exchange data. Exposure can make impersonation, targeted phishing, or linking information from multiple sources easier. But technical accessibility alone does not prove that anyone downloaded the data in bulk or misused it.

What the ministry confirms — and what remains open

The Czech Ministry of Justice said the national numbers and AIFO codes did not appear on ordinary pages, extracts, or search results. According to information it received from the supplier, the values were present in a technical server response; finding them required deliberately opening that response or calling the relevant interface outside the portal’s standard user experience. There is an important difference in emphasis: independent reporters verified that the data could be reached, while public accounts differ on how straightforward that access was and whether it counts as access during ordinary use. Source: The Czech Ministry of Justice’s statement

After being alerted, the ministry restricted access to the affected part of the system and then took the test portal offline. It notified the Czech National Cyber and Information Security Agency and the Office for Personal Data Protection. The existing business register continued to operate, the ministry said. It has not yet confirmed how many people may have been affected or whether third parties actually obtained the data. The investigation is ongoing, and the ministry says its findings do not confirm a mass data breach. Source: The ministry’s update on its response and investigation

The case is a reminder that calling an environment “test” does not protect real data. If a test system contains live records or connects to production services, an access-control flaw can have consequences similar to one in production. It is also important to distinguish between data that was technically accessible, data someone actually obtained, and confirmed misuse. Reporters verified the first two flaws; the ministry is still assessing whether and how much data was accessed.

For readers, an important distinction is that this was a test version of a portal under development, not a failure of the entire Czech business register. But the test was publicly reachable and handled real people’s data. Even a temporary system opened for feedback needs clear decisions about which data it may process, who can access them, and how access is recorded. Calling an environment “test” does not replace access controls or personal-data safeguards.

The difference between data shown on a page and data contained in a server response is technical, but it is not a reason for an organization to pay less attention. A browser can hide a field that the interface does not need to render while still receiving it. A document may have an unpredictable identifier, yet remain accessible if the server does not check ownership or permission. Security testing therefore needs to exercise direct server requests, vary record identifiers, and confirm that users can retrieve only records they are entitled to see.

Restricting access quickly can limit further exposure, but it does not answer whether anyone had already downloaded the data, who accessed it, or whether it appeared elsewhere. Those questions require server logs to be preserved and assessed against timing, accounts, and request volumes. Notifying the relevant authorities is part of incident response; it does not mean investigators have already established the scope or assigned responsibility. Those conclusions should wait for evidence from the ongoing investigation.

Three practical steps for organizations

  1. Use fictional or carefully anonymized data in tests. Separate test environments from production databases and restrict their access to live services.
  2. Check authorization at every server interface. Hiding a field in the user interface is not enough; access checks must also apply to direct API requests and attempts to change a record identifier.
  3. Monitor access and rehearse the response to a flaw. Log unusual bulk requests, assign an incident owner, and prepare steps to restrict access, preserve evidence, and notify the responsible parties.

Organizations should be able to show that test systems contain only appropriate data and that every interface checks permissions. Source: Živé.sk’s coverage and comparison of the responses

Sources