Disclaimer: This report reflects the submitter's account. It has not been independently verified unless marked Verified. The company may dispute this claim.
Scam Alert: zorgenzekerheid.nl — Zorg en Zekerheid- UNPROFESSIONALISM & SEVERE VIOLATIONS OF GDPR/ RISKY APPLICATIONS- USERS RISKS
Company / Program: zorgenzekerheid.nl
Platform: Other · Severity: high · Scam type: ignored
Published:
Reported by: Anonymous
Background
-----------
As of 12 May 2026 dismissing all reported issues in 61x reports as non‑issues. After thorough re‐analysis, we find zorgenzekerheid.nl justifications unsubstantiated and in stark conflict with widely accepted security standards and legal requirements. Below we provide a detailed, point‑by‑point summary of the confirmed vulnerabilities, their impact, and the company’s flawed responses. We also highlight relevant Dutch and European legal obligations (NEN 7510, AVG/GDPR) and industry best practices (OWASP, CWE) that they appear to neglect. Our aim remained to secure users’ data and systems and ensure compliance; but were met with dismissal. In light of zorgenzekerheid.nl inaction and misunderstanding of the risks, we now formally document these findings and outline next steps for all stakeholders.
Timeline of Reports and Responses
------------------------------------
- 5 April 2026: We submitted “Batch ReTest Reports #001–#058” (Android app) and “Batch ReTest Reports #059–#061” (iOS app) detailing 61 distinct high‑severity issues (as summarized below).
- 12 May 2026: Your security team replied that none qualify as “High/Critical” vulnerabilities, citing reasons like “not in our code”, “standard library behavior”, or “not reproducible.”
- 2 July 2026: We sent a final disclosure notice (“WARNING!! FINAL OPEN DISCLOSURE…”), indicating our intent to escalate to CERTs, regulators, and public forums (as responsible practice in coordinated vulnerability disclosure).
- Present (July 2026): Having received no constructive response, we are formally publishing these findings. We also note that similar disclosures to other organizations have been validated and rewarded, emphasizing that our methodology and findings are sound.
Each stage above is documented in our correspondence (and is summarized here). Given the repeated dismissals, we now proceed with public / necessary quarters engagement to protect users and ensure compliance.
Summary of Reported Vulnerabilities
------------------------------------
In total we reported 61 issues (58 on Android, 3 on iOS), mostly High or Critical, including most severe ones were: -
- BRT#024–#025 (Android): Critical – Hardcoded URLs and OAuth credentials (Firebase Ad ID and Google OAuth tokens) embedded in code. These allow large‑scale privacy violations, unauthorized API usage, and user tracking. (Category: Insecure Data Exposure / Hardcoded Credentials.)
- BRT#031 (Android): Critical – Hardcoded default and logout URLs in WebView navigation. An attacker could force sessions to end or redirect users to malicious endpoints. (Session Hijacking Risk.)
- BRT#009 (Android): High – Missing Network Security Configuration. The app allows SSL interception (Man‑in‑the‑Middle) because cleartext is not fully blocked and certificate pinning is absent. (Category: Insecure Communication, CWE‑319).
- BRT#038 (Android): High – An exported main activity with insufficient URL domain whitelisting. A rogue app can launch it via intent, causing privilege escalation or spoofed content. (Category: Improper Export of Android Components, CWE‑926.)
- BRT#047 (Android): High – WebView debugging was enabled in production. This debug code allows full inspection and JavaScript injection into in‑app web content. (Category: Active Debug Code, CWE‑489.)
- BRT#049 (Android): High – JavaScript injection into a WebView through an exported interface. A malicious webpage can call app methods, potentially exfiltrating sensitive data. (Category: Exposed Dangerous Method, CWE‑749.)
- BRT#058 (Android): High – Use of MD5 hashing for data integrity. MD5 is cryptographically broken; this enables hash collisions and integrity bypass. (Category: Broken Cryptography, CWE‑327.)
- BRT#059 (iOS): High – Missing Privacy Manifest (PrivacyInfo.xcprivacy) in the iOS app. Apple now mandates this manifest for all SDKs (since May 2024) to disclose data collection. This omission violates Apple policy and undermines user privacy disclosures.
- BRT#060 (iOS): High – Hardcoded Google OAuth Client ID in the app binary. This enables attackers to impersonate the app or abuse APIs. (Category: Hardcoded Credentials, CWE‑798.)
- BRT#061 (iOS): High – Use of a non‑persistent data protection class (weak file encryption). Data remains accessible after device lock. (Category: Weak Cryptographic Practice, CWE‑327.)
These reports illustrate systemic issues: misconfigurations, insecure defaults, and hardcoded secrets. They span multiple OWASP and CWE categories (e.g. Security Misconfiguration (OWASP M8), Inadequate Privacy Controls (M6), etc.) and would be readily exploitable in the real world. For instance, CWE‑926 warns that any “exported Activity not properly restricted” can let malicious apps gain sensitive access or alter the app’s internal state. CWE‑489 warns that “active debug code can create unintended entry points or expose sensitive information”, potentially granting an attacker complete con