Tuesday, August 5, 2025

Aiman Al-Hadhrami Hackerone Privacy


Design Flaw in HackerOne’s Profile Visibility: A Privacy Violation (CWE-359) Under GDPR and ISO/IEC 27701




By: Aiman Al-Hadhrami

Independent Cybersecurity Researcher


❖ Introduction

In today’s digital era, privacy is not optional — it is a fundamental right, protected by global regulations like the General Data Protection Regulation (GDPR) and international standards such as ISO/IEC 27701, which emphasizes privacy by design and user control over personal data.

This post highlights a critical privacy concern on HackerOne, a well-known vulnerability disclosure platform, where users lack any control over the public visibility of their profiles and reputation scores — a design decision that may contradict their publicly stated compliance with GDPR and ISO 27701.


❖ What’s the Problem?

Currently, HackerOne user profiles are publicly visible by default, including:

  • Username
  • Profile activity
  • Reputation score

And most importantly:
There is no setting or control that allows users to hide or restrict this information.


❖ Why This is a Privacy Violation

1. Contradiction of GDPR Article 25:

Article 25 requires data protection by design and by default.” This means:

“By default, personal data should not be accessible to an indefinite number of people without the individual’s intervention.”

But on HackerOne:

  • Profile data and scores are public by default
  • No explicit consent is obtained for public exposure
  • No privacy settings are offered to limit visibility
  • Profiles are indexed by search engines without user opt-in

2. Misalignment with ISO/IEC 27701:

HackerOne publicly claims to follow this privacy management standard. However, ISO 27701 clearly emphasizes the need for user control, minimization of public exposure, and consent-driven data sharing — none of which are currently enforced on the platform.


❖ Real-World Impact on Users

Publicly exposing reputation scores — especially negative ones — without user control or contextual explanation can lead to serious consequences:

  • Professional harm and reputational damage
  • Misinterpretation of the user’s behavior as malicious or unethical
  • Loss of job opportunities, trust, or career growth
  • Emotional distress and stigmatization
  • Discouraging ethical hackers from using the platform

Reputation scores may be negatively impacted by reports closed as “Not Applicable,” even when such reports were submitted in good faith. This outcome does not imply that the report lacks validity, but may instead reflect limitations in the platform’s internal policy or scope. 

Yet outsiders often interpret such scores harshly and unfairly. It is unfair for HackerOne to publicly display a negative reputation score without giving users control to hide or explain it. Privacy is a right, not a luxury!


❖ Lack of Transparency in Reputation Penalties: A Digital Injustice

When a report is closed as "Not Applicable", the researcher is automatically penalized with -5 reputation pointswithout any public explanation.

This deduction becomes publicly visible on the researcher’s profile and can easily be misinterpreted by the general public, employers, or peers as a sign of incompetence, negligence, or even malicious behavior. In reality, many of these reports are submitted in good faith but rejected due to program scope limitations or internal platform policies, not because the report was invalid or unethical.

The bigger issue is that HackerOne does not allow researchers to disclose these specific reports to the public. This means that researchers have no ability to explain or defend why they lost points, even if they acted responsibly.

This creates a system where:

  • Reputation is damaged without context
  • Users are judged without transparency
  • Researchers are denied the ability to control their own narrative

According to Article 5 of the GDPR, personal data must be:

“Processed lawfully, fairly, and in a transparent manner...”

In this case, there is no transparency, no fairness, and no informed consent — which clearly contradicts the core principles of data protection and ethical platform design.


❖ A Privacy and Design Flaw — Not Just a Feature Request

This is not a bug in code, but a flaw in platform design — a violation of basic Privacy Engineering principles and user autonomy.

In security classification terms, this falls under:

CWE-359: Exposure of Private Information (‘Privacy Violation’)


❖ Evidence of Inconsistency:

HackerOne states publicly: 

> "We comply with ISO 27701 which provides requirements for a privacy management system within the context of an organization..." 

> "We ensure our data collection and handling practices comply with the General Data Protection Regulation (GDPR) and its rules on data protection, privacy, and transfer..."

In reality:

  • Users have no privacy or visibility controls
  • Personally identifiable information is public by default
  • Reputation scores are publicly visible without context or consent
  • Search engine indexing is enabled by default

This reveals a clear gap between HackerOne’s stated commitments and actual user experience.


❖ Proposed Solutions for Hackerone

To align with privacy standards and user expectations, I propose the following actions:

  1. Set profile visibility to private by default, in accordance with GDPR Article 25.

  2. Or Introduce Profile Visibility Settings, including: 

    • Public
    • Private 
    • Unlisted
  3. Allow users to hide or restrict visibility of reputation scores, particularly negative ones.

  4. Use a more neutral term such as "Contribution Score" or "Participation Rating" instead of "Reputation" to avoid harmful interpretations.

  5. Allow users to disclose "Not Applicable" reports voluntarily, so they can defend the context of the negative score and avoid misjudgment.

  6. Implement contextual tooltips or explanations for reputation deductions visible on public profiles (e.g., “Score impacted by a report closed as Not Applicable”).

  7. Introduce a right to appeal or explain score deductions, especially when they result from vague or non-transparent rejections.


❖ Why This Matters

This issue is not just about convenience — it’s about:

  • Protecting users from unintentional reputational harm
  • Ensuring legal compliance with privacy regulations
  • Promoting ethical platform design
  • Preserving trust in the security community

On a platform called HackerOne, where misunderstanding the term “reputation” could lead to damaging assumptions, users deserve better protection, transparency, and control over how they are publicly portrayed.


❖ Conclusion

A platform that promotes ethical hacking should not expose researchers to reputational damage simply for engaging responsibly.  A platform that promotes transparency, ethical hacking, and legal compliance should hold itself to the same standards it encourages in others. Before expecting researchers to act with integrity, it must first reflect that integrity in its own practices — by respecting user privacy, adhering to internationally recognized data protection frameworks such as GDPR Article 25, ISO/IEC 27701. Leadership in cybersecurity and privacy begins with internal accountability and a commitment to compliance by design.