Government Portal Security in South Africa: What the DCS Breach Revealed

The Department of Correctional Services sample data that Nullsec Nigeria published in May 2026 contained bid invitation notices, tender results, council resolutions, and an annual report. Most of it was material the South African government is legally required to publish. A researcher with a browser and two hours could have assembled the same package.

That observation deserves more attention than the breach claim itself. When a hacktivist group's claimed 11GB haul looks like a scrape of public directories, it means the directories were walked, the API endpoints were queried directly, and the sequential record IDs were enumerated until the storage was empty. That is the dominant attack pattern in South African government and parastatal IT, and most organisations running those portals have never run that test on themselves.

What the DCS sample data tells us about how SA portals get scraped

The single item in the DCS sample that does not fit the public-record pattern is a handwritten tender document. Handwritten supplier tenders are not routinely published on government websites. Their presence in the sample points either to a misconfigured file upload directory where supplier-submitted documents were directly browseable, or to something more serious. The former is what I find in the majority of SA portal audits.

In audits across SA government, parastatal, and municipal clients, the patterns that surface consistently are: bid evaluation pages that load when the URL is entered directly even though the supplier menu hides them; API endpoints that return full banking details despite the interface showing them masked; bid attachments stored in publicly readable cloud storage with predictable filenames; and sequential integer IDs in URL parameters that return a different supplier's data when incremented by one. A motivated attacker maps which combination applies to a specific portal in about half a day, then runs an automated extraction pass.

What Ubuntu Guard found across three SA portal audits

The following are aggregated findings from engagements during 2025 and 2026. Specific clients and platforms are not named.

• Insecure Direct Object References Critical
  Found in 2 of 3 audits

  Sequential bid IDs in URL parameters returned another supplier's data when incremented.

  Fix: Enforce an ownership check in the API layer, not the interface layer.

• Publicly Readable File Storage High
  Found in 3 of 3 audits

  Bid attachments stored in cloud storage buckets accessible without authentication, with sequential or guessable filenames.

  Fix: Move to authenticated storage with pre-signed, expiring URLs.

• Directory Listing Enabled High
  Found in 2 of 3 audits

  Visitors could browse /uploads, /temp, or similar directories directly in a browser without logging in.

  Fix: Options -Indexes on Apache, autoindex off; on Nginx. Under 10 minutes to implement.

• Unauthenticated Administrative Endpoints Critical
  Found in 1 of 3 audits

  An internal export endpoint returned structured supplier data in JSON to anyone who knew the URL, without requiring any login.

  Fix: Enforce a role check on the endpoint.

• Excess Personal Information in Published Awards Medium
  Found in 3 of 3 audits

  Published award notices contained full ID numbers and personal contact details beyond what the public-records framework requires.

  Fix: Apply a redaction policy before publication. Defensible under POPIA.

• No Rate Limiting on Supplier Search Medium
  Found in 2 of 3 audits

  The supplier search API could be queried thousands of times per minute, enabling bulk enumeration of the supplier database.

  Fix: Rate limiting at the API gateway.

What a properly secured procurement portal looks like

A well-secured procurement portal has these baseline characteristics. None require advanced security work. All require deliberate configuration.

• Access control enforced at the data layer — every API call checks role and ownership before returning data
• File storage behind authentication — bid attachments stored with pre-signed, expiring URLs
• Directory listing disabled at the web server layer
• ID schemes that are not predictable — UUIDs instead of sequential integers in URLs
• Rate limiting on all public-facing APIs
• Redaction policy for published award notices — limits personal information that becomes public
• Quarterly external penetration test

POPIA obligations for portal operators

Procurement portals hold personal information: banking details, ID numbers, signatory contact details, and tax clearance numbers. Under POPIA, these qualify as personal information regardless of whether the supplier is an individual or a company with named natural persons attached to the record.

Three POPIA considerations are specific to portal operators:

Section 22 notification applies to portal exposures the same way it applies to database breaches. The Information Regulator does not apply a minimum-quantity threshold. Reasonable grounds to believe personal information was accessed without authorisation is sufficient to trigger the reporting requirement.

The minimisation principle requires that personal information not be collected or retained beyond what is strictly necessary. Many SA procurement portals collect more personal detail than the procurement process requires. Reducing the dataset is both a compliance measure and a security one.

Cloud-hosted portals where the storage layer sits outside South Africa require a documented assessment under Section 72 before transferring supplier data to overseas infrastructure.

Six things to check on your portal this quarter

1. Crawl it as an unauthenticated visitor. Walk the URLs yourself or use a site spider. Compare what loads without a login against what you intend to be publicly accessible.
2. Walk the record IDs. Find every URL parameter that looks like a sequential integer. Increment it. Confirm the resulting page shows only data your own account owns.
3. Test the API directly. Most portal exposures sit in the API layer, not the interface. OWASP ZAP is a free tool that makes systematic API testing straightforward.
4. Check file storage. Try accessing your upload directory in a browser without logging in. If you see a file listing, or can download a supplier's bid document without logging in, your configuration is wrong.
5. Disable directory listing on the web server. Options -Indexes on Apache, autoindex off; on Nginx. This is a configuration change that takes under two minutes.
6. Schedule an external penetration test. Once a year is the minimum for a static portal. More frequently if the platform is actively developed.

Where Ubuntu Guard fits

Ubuntu Guard runs public-facing portal hardening reviews for SA municipal, parastatal, and SME organisations. We walk your portal as an attacker would, document every finding with reproduction steps, and hand over a prioritised remediation list. If the DCS exposure pattern sounds familiar, the conversation before a researcher finds it is a better one to have.

Reach us at [email protected]

Frequently asked questions

How do I test whether my procurement portal has IDOR vulnerabilities?

Find any URL in your portal that contains a numeric ID parameter. While logged in as a standard user, increment or decrement the number. If the resulting page shows data belonging to another user, supplier, or tender record, you have an IDOR vulnerability. OWASP ZAP automates this process for comprehensive coverage.

Does POPIA apply to data exposed through a misconfigured portal?

Yes. Procurement portals hold personal information, and POPIA's Condition 7 requires responsible parties to implement reasonable technical and organisational safeguards. An unauthenticated endpoint returning supplier records does not meet that standard. If a third party accesses that data, Section 22 notification obligations may apply.

What is the difference between the DCS sample claim and a confirmed breach?

The DCS sample published by Nullsec Nigeria consisted largely of documents the government is required to publish. That is consistent with directory scraping or API enumeration rather than internal system compromise. Without forensic analysis of server logs, the two scenarios cannot be distinguished from outside. The practical implication is the same: if your portal has these structural weaknesses, the same technique works regardless of who runs it.

© 2026 Ubuntu Guard Cybersecurity | Durban, South Africa
ubuntuguard.co.za