This is a vulnerability disclosure program for all of my personal projects and code that I publish.

| ⏳ Disclosure policy |

|-|

I will investigate legitimate reports and make every effort to quickly resolve any vulnerability. Please make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of my services.

I will not pursue civil action or initiate a complaint to law enforcement for accidental, good faith violations of this policy. I consider activities conducted consistent with this policy to constitute “authorised” conduct under the Computer Fraud and Abuse Act. I will not bring a DMCA claim against you for circumventing the technological measures I have used to protect the applications in scope of this program.

If legal action is initiated by a third party against you and you have complied with this security policy, I will take steps to make it known that your actions were conducted in compliance with this policy.

It is also important to note, I will not take legal action against you simply for providing me with a proof of concept of the security vulnerability. Please follow the guidelines listed in the Proof of concepts section below to ensure that your proof of concept is detailed enough to demonstrate the issue and still follows the guideline listed above.

If you have any questions or concerns about about my disclosure policy, please do not hesitate to contact me via Twitter or email (contact [a t] edoverflow [d o t] com).

| ? Process |

|-|

{F241462}

| ? Service-level agreement (Performance expectations) |

|-|

I will make a best effort to meet the following expectations for hackers participating in this program:

Time to first response: 2 business days or less.

Time to triage: 3 business days or less.

| ? In-scope |

|-|

All projects listed in the "In Scope" section at the very bottom of this page are in scope. If an asset is not listed below, please always verify that the security.txt file points to this page. If it doesn't, then that project does not belong to me.

```

$ curl http://example/.well-known/security.txt

This project is in scope!

Contact: https://hackerone.com/ed

```

| ⚠️ Exclusions |

|-|

The following test types are excluded from the scope:

• Findings from physical testing such as office access (e.g. open doors, tailgating).

• Findings derived primarily from social engineering (e.g. phishing, vishing).

• Findings from applications or systems not listed in the "Scope" section. I do accept high-severity issues on out of scope assets if they directly affect me.

• Vulnerability reports with video only PoCs.

• Reports that state that software is out of date or vulnerable without a proof of concept.

• Highly speculative reports about theoretical damage. Be concrete.

• Vulnerabilities as reported by automated tools without additional analysis as to how they’re an issue.

• Issues in third-party services should be reported to the respective team.

The following issue types are excluded from scope:

| Description | Reason |

|-------------|--------|

| Network-level Denial of Service (DoS/DDoS) vulnerabilities. | I do not want you to disrupt any of my services and to be honest with you if I want to take down a service I will always find a way. |

| Low severity issues that can be detected with tools such as Hardenize and Security Headers. | I run regular scans with these services and try to improve my score gradually. |

| Content injection issues. | The severity of this issue is so low that it does not warrant a report. |

| Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.). | In order for CSRF to be a valid issue it must affect some important action such as deleting one's account. |

| Missing cookie flags. | These type of issues do not present a major risk and are usually picked up by scanners. |

| UI and UX bugs (including spelling mistakes). | No comment. |

| 401 injection. | This is usually an accepted risk. |

| Stack traces that disclose information. | Most of my projects are open-source therefore this information is usually public knowledge. That said, if you discover a stack trace that discloses information which is not located in my GitHub repositories, please do submit a report. |

| Host header issues without an accompanying proof-of-concept demonstrating vulnerability. | PoC or GTFO. |

| Open ports without an accompanying proof-of-concept demonstrating vulnerability. | Same as above. |

| Banner grabbing issues (figuring out what web server I use, etc.). | I will happily share what web servers I am running. |

| Missing X-Frame-Options header (Clickjacking) | The lack of X-Frame-Options does not always indicate that a security vulnerability is present. This is an optional header that is only necessary on endpoints where the UI is rendered to invoke state changing actions. |

| Cross-site tracing | In order for Cross-Site Tracing (XST) to really be a significant issue you would need to find an endpoint vulnerable to Cross-site Scripting (XSS). |

| CSP uses unsafe-inline | The fact that a CSP includes unsafe-inline is not an issue in itself. In order for you to demonstrate the actual impact of this value, I highly recommend you look for an XSS vulnerability. Try to trigger alert(document.domain). |

| Disclosure of robots.txt file | I am aware that in some cases robots.txt files have been known to disclose sensitive information. In my case I have determined that my robots.txt files do not contain any information that poses a potential security risk. |

| Email spoofing (SPF misconfigurations) | I have accepted the risk that this issue poses and do not believe that it warrants an immediate fix. |

| Open redirect using Host header | Open redirects in the Host header are not exploitable. |

| Proving me wrong on Twitter. | |

| ? Proof of concepts |

|-|

| Issue type | When to report the issue |

|------------|--------------------------|

| XSS | For XSS, a simple alert(document.domain) should suffice. Bonus points for alert('?'). |

| RCE | Please only execute harmless code. Simply printing something or evaluating an expression should be enough to demonstrate the issue. |

| SQLi | Report it as soon as you have a SQL error that indicates SQL injection or you are able to disclose the SQL server's version number. |

| Unvalidated redirect | Set the redirect endpoint to http://example.com. |

| Information disclosure | If your report contains sensitive data, please use my PGP key to encrypt it. |

| CSRF | Either attach a file to demonstrate the issue or paste the code in a code block in your report. |

| SSRF | Do not go playing around on any internal networks. Leave the fun bit to me. If you feel the necessity to retrieve an internal file, please only request the internal security.txt file. |

| LFI | The same applies here — please do not go against the guideline listed in the Disclosure policy section. There should be a security.txt file located in the root directory. Being able to retrieve that file should be enough to demonstrate the issue. |

| ? Advice |

|-|

• I encourage hackers to read Web Hacking 101 and Breaking into Information Security: Learning the Ropes 101 to get a good idea of the type of issues that I am looking for.

• If you have a question, please do not hesitate to include it in the report. I am always here to help. You may also contact me directly via Twitter DMs or email (contact [a t] edoverflow [d o t] com). If your messages contain sensitive information, I would prefer you use the latter with my PGP key:

```

$ curl https://edoverflow.com/key.asc | gpg --import

```

| ? Terminology |

|-|

The term "severity" is frequently used interchangeably with "impact" or "priority". This section defines my terminology in order to prevent any potential confusion. I use the Oxford Dictionaries' definition [2] of "severity" and Information Technology Infrastructure Library's definitions [3] of the two latter terms.

Severity

> The fact or condition of being severe.

Impact

> A measure of the effect of an incident, problem or change on business processes. Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority.

Priority

> A category used to identify the relative importance of an incident, problem or change. Priority is based on impact and urgency, and is used to identify required times for actions to be taken.

Whenever I triage a report, a CVSS v3.0 Base Score metric [4] is set which evaluates the technical severity of the reported issue and allows me to prioritise the fix. Once a patch has been submitted and verified, I will then evaluate the total CVSS score by including the Environmental Score. [5]

| ? Rewards |

|-|

I am not currently offering financial rewards as my software is free and open-source, but if we ever meet in person drinks are on me. Please note that this section may change in the future.

{F240600}

Thank you for helping me keep my projects safe!

| References |

|-|

1. Cover image courtesy of HackerOne.

2. ITIL glossary and abbreviations https://www.axelos.com/corporate/media/files/glossaries/itil_2011_glossary_gb-v1-0.pdf

3. Oxford Dictionaries https://www.oxforddictionaries.com/

4. Base Metrics: https://www.first.org/cvss/specification-document#2-Base-Metrics

5. Environmental Metrics: https://www.first.org/cvss/specification-document#4-Environmental-Metrics

```

      _,-.     --------------------

,-. ,--' o ) -( Frogs find bugs! )

(,' ' ,,-' --------------------

,-.-.__,\_

('--' '\

```