Skip to main content
HEMA Information Security HEMA Information Security

Responsible disclosure

Did you find a potential vulnerability in a HEMA website or system? Read here how to report this through our responsible disclosure process.

responsible disclosure process #

Although we put tremendous efforts in keeping our systems secure at HEMA, there can always be vulnerabilities that remained unnoticed to us. Whenever you find a (potential) vulnerability that may cause an issue to our systems or leads to disclosure of our (customer) data, we kindly ask you to report this to us so that we can remediate it and better protect our customers and systems.

To disclose a vulnerability, please adhere to the following:

  • Share your findings by completing the form below, if you want to include screenshots or a formatted write-up upload this in PDF-format.
  • Do not take advantage of the vulnerability or problem you have discovered, for example by downloading more data than necessary to demonstrate the vulnerability or deleting or modifying other people’s data.
  • Do not reveal the problem to others until it has been resolved. Please refrain from publishing any information until we have proofread the content and provided our OK, to ensure no sensitive information is disclosed.
  • Do not send unnecessary messages and do not address groups of people to, for example, ask for updates or rewards.
  • After your report has been closed, you will delete any confidential information obtained during your investigation.

When correctly following the responsible disclosure process, we promise to:

  • Analyze your report and get back to you within five working days after submission.
  • We will never take legal actions against you, if rules of the disclosure process are followed.
  • We will handle your report with strict confidentiality and will never pass on your personal details to third parties without your permission.
  • We will keep you informed of the progress towards resolving the problem.
  • If so desired we will mention your name/handle on our acknowledgements webpage, this is optional and only after your explicit approval.
  • We will provide your name as the discoverer of the problem (unless you desire otherwise).
  • As a token of our gratitude for your assistance, we offer a reward for every valid report of a security problem that was not yet known to us. Payment will be made after the issue is remediated. The amount of the reward depends on amongst others; the impact for HEMA and the accuracy of the report. The final amount will be determined by HEMA. The reward is entirely at the discretion of HEMA and is non-negotiable.
  • After remediation, we are happy to review your write-up/blog/video if you wish to publish your finding.

rewards #

Depending on the severity of the identified vulnerability, we will provide a reward varying from delicious HEMA pie to HEMA gift cards valued €100,- to €250,-.

definition of a vulnerability #

HEMA considers a security vulnerability a weakness in our websites or infrastructure that could impact confidentiality, integrity and/or availability of these systems. Because this is a broad definition, we understand you might raise concerns that are already known or not considered a security issue by HEMA. To provide some clarity, the following types of findings are not defined as security vulnerabilities:

  • Auto-completion enabled or disabled on forms.
  • Missing cookie attributes on non-sensitive cookies, for example missing HTTP-only flags on analytics cookies.
  • Presence or absence of HTTP headers, such as: X-Frame-Options, CSP, no-sniff, etc. Unless part of a solution for another related vulnerability.
  • DNS dangling and subdomain take-over,
  • Email security measures such as DKIM, DMARC and SPF.
  • SSL/TLS findings that pertain to outdated or invalid certificates.
  • Certain low-risk vulnerabilities or risks that are already known. These may still be security vulnerabilities, but either already in remediation or accepted.
  • Vulnerabilities of the same type, reported separately, for example XSS in multiple parameters or unvalidated redirects in different locations. These are considered one vulnerability.

The list below are things we would definitely consider a security vulnerability:

  • Unauthorized access to customer data, including but not limited to names, order information and further personal details.
  • Remote Code Execution (RCE).
  • Server-Side Request Forgery (SSRF).
  • Cross-site Scripting (XSS).
  • Cross-site Request Forgery (CSRF).
  • Injection attacks, such as SQL Injection (SQLi).
  • XML External Entity Attacks (XXE).
  • Access Control Vulnerabilities (Insecure Direct Object Reference issues, etc.).
  • Path/Directory traversal Issues.

When in doubt, feel free to submit a (potential) vulnerability to our security team for our review/consideration.

report a vulnerability #

If you believe you have found a security issue that we would consider a security vulnerability or have something else you would like to bring to our attention, use the form below this page ‘Report vulnerability’ (requires JavaScript).

Alternatively, contact us via email .