- 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
We permanently monitor our server 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. Hardening means that we removed unnecessary packages and applied strict configuration at the kernel level. Finally, we implemented processes to ensure the 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 significant 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 the 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 five 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 the ineligibility of your report.
Afterward, 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. We include the actual bug bounty 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 still be 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 the domain name must be in scope.
- Your report must be sent via the channels mentioned above, must clearly describe the potential vulnerability, must include a step-by-step description that allows us to reproduce the issue, and may consist of 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 March 27, 2020. For transparency, we provide a complete changelog of this page on codeberg.orgexternal link .