Security and responsible disclosure
This page tells you how to report a security problem with SassaCheck, what we cover, and what we promise you in return.
How to report a vulnerability
Email hello@sassacheck.org.za with the details, and we will reply within two business days.
Put the word "security" in your subject line so your message is not read as a grant query. You do not need to work out how serious the problem is before you send it. If something looks wrong, tell us and we will look.
Send us:
- The address you were testing, either a page on sassacheck.org.za or a path on the proxy.
- The steps you took, in order.
- What you expected to happen, and what happened instead.
- The date and time, with the time zone.
- Whether personal information was involved, and what kind. Do not send the information itself.
- A name or handle to use if you want credit, and the best way to reach you.
SassaCheck is an independent service run by a private operator, not by a government body. Operator, registration and Information Officer details are available on request. Contact us at hello@sassacheck.org.za.
What is in scope
The SassaCheck website and the status-check proxy behind it are in scope. SASSA's own systems and the hosting platform under us are not.
The proxy is the small service at our Johannesburg-hosted Google Cloud Run API. It takes your ID number and cellphone number, passes them to SASSA's public status service, and sends the answer back to your screen. We do not save raw ID numbers, cellphone numbers or status results in our application database. Keyed security hashes, request counters and operational logs are retained separately; see our data-handling explanation.
In scope
- The site at sassacheck.org.za, including its pages, forms, response headers, redirects and the security.txt file.
- The proxy at our Johannesburg-hosted Google Cloud Run API, including its input checks, rate limits and error responses.
- The home-page checker processes your ID number and cellphone number through our server to retrieve your result from SASSA. It does not save the raw ID, phone number or result in its application database. Separate security counters and hosting logs are retained as described in our privacy policy.
- Anything that lets one person use the proxy to look up another person's status, or that gets around the rate limits.
- An input the proxy accepts when it should reject it, such as an ID number with a bad check digit or a cellphone number in the wrong format.
- Email spoofing of sassacheck.org.za, including an SPF, DKIM or DMARC failure that would let someone send mail as us.
- Any page or form on our site that asks for a PIN, a password, an OTP or a card number. We never ask for these, so if you see one, it is a bug or it is not our site.
What the proxy is built to do
- Accept POST requests only. Your ID number is never in a URL.
- Check the ID number's format, its date prefix and its check digit, and the cellphone number's format, before anything is sent.
- Limit requests using keyed HMAC hashes of the IP address and applicant ID. Counter expiry is refreshed to 10 minutes after an allowed request; expired records are deleted asynchronously. When a limit is reached, the API returns a rate-limit response without a status result.
- Google Cloud request and error logs can include IP address, request URL, time, status, latency and user agent. Our application does not log request bodies or status results. The default operational log bucket retains records for 30 days; separate administrative audit logs have a 400-day retention period.
- Send no-store on every response, so no result is cached.
- Accept requests only from sassacheck.org.za.
- Time out after 20 seconds, with at most one retry.
- Have no admin panel that accepts an ID number.
If you find a gap in any of these, that is exactly what we want to hear about. Our How it works page describes the full data flow.
Out of scope
- srd.sassa.gov.za and sassa.gov.za. We cannot fix those, and our safe harbour does not cover testing them. Report a problem there to SASSA. Our SASSA contact details page lists the channels.
- Firebase Hosting, Google and any other platform we build on. Report those to the provider, and tell us as well if the problem affects this site.
- Denial-of-service tests, load tests and high-volume scanning. These slow the site for people checking a grant, and they are not covered by safe harbour.
- Any test that uses someone else's ID number or cellphone number.
Rules for testing
Use only your own details, keep the volume low, and stop as soon as you can show the problem.
- Test with your own ID number and your own cellphone number. If a test needs a number the proxy should reject, use a made-up one and say so in your report.
- Never try to reach another person's status, personal information or account.
- Do not run denial-of-service tests, load tests or high-volume scans. Our rate limits will block them, and they slow the site for everyone else.
- Respect robots.txt. It asks crawlers to stay out of /api/.
- Change nothing and delete nothing. Do not upload anything beyond what you need to show the problem.
- Stop when you have shown the problem. Do not keep going to see what else you can reach.
- Give us time to fix it before you publish. Tell us in your first email if you plan to write about it, and we will agree a date with you.
Safe harbour
If you follow the rules on this page, we will not take legal action against you or report you to anyone for testing our site.
We will treat your testing as allowed. We will not send a lawyer's letter, and we will not ask a host, a registrar or a service provider to act against you. If you want that in writing, ask, and we will confirm it in our reply.
This holds only if you:
- test only the in-scope systems listed above;
- follow the testing rules;
- report the problem promptly and use it for nothing else;
- do not access, keep or share anyone else's personal information; and
- do not publish the details before we have fixed the problem or agreed a date with you.
What safe harbour does not cover
It does not cover SASSA's systems, third-party platforms, or anyone who uses a finding for something other than reporting it.
- SASSA's systems. This promise is ours alone, and we have no power over them.
- Firebase Hosting, Google or any other third party.
- Anyone who reads, keeps or shares personal information that is not theirs.
- Anyone who harms users, the site or the proxy.
Bug bounty
SassaCheck does not run a paid bug bounty programme.
We will still read every report, fix what we can, and tell you when the fix is live. If you want credit, tell us the name or handle to use. We will ask before we mention you anywhere.
What happens after you report
We reply within two business days, tell you what we found, and tell you when the fix is live.
- We acknowledge your email within two business days.
- We check the report against the site and the proxy, and ask you for anything else we need.
- We fix the problem. We will not give you a fix date we cannot keep. If it will take longer, we will say so.
- We tell you when the fix is live.
- If you want to publish, we agree a date with you. We will not ask you to stay quiet for longer than the fix takes.
- If we cannot fix something, we will tell you, and we will explain why.
If you ask, we will confirm in writing that your report was handled under this page.
Where to find security.txt
Our security.txt is at https://sassacheck.org.za/.well-known/security.txt.
The file gives our contact address, the date it expires, the language we answer in, and the URL it applies to. It carries the same contact address as this page.
If the file and this page ever disagree, email hello@sassacheck.org.za and tell us. We will fix whichever one is wrong.
If your problem is about your grant, not security
This address is for security reports only, so for a grant problem please contact SASSA.
SassaCheck can request a status lookup but cannot approve, decline, suspend, reinstate or speed up a grant. Use official SASSA services for changes to your application.
- Toll-free: 0800 60 10 11
- WhatsApp: 082 046 8553
- Email: srd@sassa.gov.za
- Status: srd.sassa.gov.za/sc19/status ↗
- Appeals: srd.sassa.gov.za/appeals/appeal ↗
Both links open srd.sassa.gov.za in a new tab. We have no control over that site. Our SASSA contact details page lists the same channels with the dates we last checked them.
SassaCheck is an independent service. We are not SASSA and not a government website. We cannot approve, decline or change any grant.
Do you pay for security reports?
No. SassaCheck does not run a paid bug bounty programme. We will still read your report, fix what we can, and tell you when the fix is live.
How quickly will you reply?
Within two business days. If you have not heard from us by then, send the email again and put "follow up" in the subject line.
Can I test with a made-up ID number?
The proxy checks the ID number's format and check digit before anything is sent, so a made-up number will not get through. Use your own number, and never anyone else's.
Can I publish what I found?
Tell us first. We will agree a date with you, and we will not ask you to wait longer than the fix takes.
Does safe harbour cover testing SASSA's website?
No. The promise comes from SassaCheck only, and it covers the systems listed on this page. Report a problem on a SASSA site to SASSA.
I received an email that looks like it comes from SassaCheck. What should I do?
Forward it to hello@sassacheck.org.za and do not click the links. We do not ask for ID numbers, PINs, passwords, OTPs or card numbers by email, and we do not ask anyone to pay to check a status.
Your ID number and cellphone number are sent over HTTPS through our server to SASSA to retrieve your status. Our checker does not save the raw ID number, cellphone number or result in its application database, and its application logging code does not record those values. The result is held in the current page memory, without saving it to cookies, localStorage or sessionStorage. For rate limiting, keyed hashes of your IP address and applicant ID are stored with request counters; their expiry is set to 10 minutes after an allowed request, and Firestore deletes expired records asynchronously. Google Cloud request logs can contain your IP address and connection metadata: the default operational log bucket retains records for 30 days, while the separate administrative audit log bucket retains records for 400 days. These audit logs are administrative records, not a 400-day database of status results. Google AdSense may use cookies and process IP, device and ad-interaction data; our code does not send status-form details or results to AdSense. We do not use a separate Google Analytics tag. See our Privacy Policy for details.
See the SASSA contacts page for current official guidance.