- We provide a security.txt file for structured security contact information.
- See our contact page for contact details and our OpenPGP key.
- Moreover, you can send encrypted messages via Keybase.ioexternal link .
For us, security and privacy take top priority
✅ No logging by default – ✅ Minimal data processing
✅ Single-purpose server – ✅ No databases
For security, we provide our blog using a dedicated virtual server. There aren't any other public services on this server (e.g., no database server, no mail server, no messaging server). For instance, the decentralized Dat version of our blog runs on another virtual server.
✅ Security monitoring – ✅ Strong authentication – ✅ Defined processes
Our server is permanently monitored to check for modified files and login attempts. Two-factor authentication is needed to access our server. The core of our server is a hardened Linux installation. This means that we removed unnecessary packages and applied strict configuration at kernel level. Finally, we implemented processes to ensure installation of security updates within a narrow time frame and quick reaction to reported potential security vulnerabilities.
✅ 100% transparency – ✅ Available on archive.org – ✅ No hidden changes
You find all changes on InfoSec Handbook on codeberg.orgexternal link . Our commits are cryptographically signed. When we update blog posts, we add a small changelog to the bottom of the blog post, listing the most important changes. Moreover, our website is listed on archive.orgexternal link . This way you can go back in history and check our changes.
Did you find a security vulnerability? You find our security-related contact details above. Besides, we run a bug bounty program to ensure the highest level of security and privacy. Everyone is eligible to participate in the program subject to the below-mentioned conditions and requirements (“disclosure policy”) of InfoSec Handbook.
We are big fans of “coordinated disclosure”. Due to this, we stay with the following process:
1. Private report
You may submit your report anonymously.
2. Eligibility check and initial feedback
We check your report for eligibility and respond within 5 days if you included any valid contact data.
Depending on the result, we either:
- fix the vulnerability and get in touch with you regarding your bug bounty and coordinated disclosure, or
- get in touch with you to request additional information, or
- inform you about ineligibility of your report.
Afterwards, we either:
- add you to Acknowledgments (upon request) and publish information about the fixed vulnerability, or
- publish information about the reported vulnerability for further discussion after 30 days if you don't send us additional information.
Scope and possible bug bounties
The disclosure policy on this page is valid for the following domain names (and underlying servers):
|Domain name||Eligible for bug bounties|
|Dat version of our blog||no|
|any other mirrors/archives||no|
The following bounties are only a guideline. The final bug bounty will be directly stated in our responses. If all testing requirements were met, we offer the following bounties:
|Type of vulnerability||Bug bounty up to|
|Information leakage (except personal data)||€75|
|Code injection (e.g., HTML, JS)||€100|
|Unauthorized access (user-level)||€100|
|Remote Code Execution (RCE)||€150|
|Leakage of personal data||€175|
|Unauthorized access (root-level)||€175|
Out-of-scope are all classes of potential vulnerabilities that aren't mentioned above, including the absence of certain HTTP response headers, vulnerabilities that require physical access to our servers, and recently disclosed 0-day vulnerabilities. Please go to our issue trackerexternal link BEFORE reporting anything, and check whether somebody already reported a potential vulnerability you found. If you report out-of-scope vulnerabilities, you may be still eligible to be listed below.
Bug bounties can only be paid via bank wire transfer (EU countries only) or Stellar Lumens (XLM). There may exist additional legal regulations and requirements.
Testing requirements and code of conduct
We won't take legal action against you as a penetration tester, if you observe the law. Moreover, we always respect your privacy. By default, we won't publish anything about you or your reports.
Furthermore, please observe our following rules:
- You must be the first reporter of a vulnerability. Please go to our issue trackerexternal link BEFORE reporting anything, and check whether somebody already reported a potential vulnerability you found.
- The reported vulnerability and domain name must be in scope.
- Your report must be sent via above-mentioned channels, must clearly describe the potential vulnerability, must include a step-by-step description that allows us to reproduce the issue, and may include additional screenshots or proof of concept code, if necessary.
- Aggressive penetration testing is strictly prohibited. By “aggressive” we mean using automated tools for untargeted attacks on our servers. Flooding our servers with millions of requests or executing random attacks neither is something a professional penetration tester does nor something that we want to see.
- In any case, you must not leak, manipulate, or destroy any data.
- Without our prior permission, you must not release anything related to the vulnerability to the public.
- We do not tolerate abusive language, harassment, any kind of criminal activity, or impersonation.
If you have any further questions, please do not hesitate to contact us.
We would like to thank the following researchers and testers:
|2019-08-28||Undisclosed||Unintended metadata in some files||€25|
We updated this page on December 7, 2019. For transparency, we provide a complete changelog of this page on codeberg.orgexternal link .