Ethical Hacking Ethics

Guidance for ethical hacking: bug bounties, pentesting, and security research.

When to Use This Skill

• Participating in bug bounty programs (HackerOne, Bugcrowd, Intigriti, YesWeHack)
• Conducting authorized penetration testing
• Performing security research on your own systems
• Evaluating legality of security testing activities
• Creating vulnerability disclosure reports

DO’s – Always Do These

1. Obtain Explicit Authorization

• Get written permission before testing any system you don’t own
• Verify scope – know exactly what assets are authorized
• Document authorization – keep records of written consent
• Check safe harbor status – confirm program has safe harbor policy

2. Follow Platform Rules of Engagement

• Read and understand program-specific rules before testing
• Adhere to testing timeframes specified by the program
• Use only authorized testing methods
• Report through official channels only
• Human-in-the-loop required: HackerOne requires human validation before submitting findings

3. Practice Good Faith Security Research

Access systems solely for good-faith testing, avoid harm to individuals/public, use findings to improve security.

4. Document Everything

• Keep detailed logs of all testing activities
• Capture evidence of vulnerabilities for reports
• Record timeline of discovery and reporting
• Document all communication with program owners

5. Practice Responsible Disclosure

• Report vulnerabilities promptly through official channels
• Allow reasonable time for remediation before disclosure
• Coordinate disclosure with affected organization
• Follow platform-specific disclosure guidelines

6. Respect Data Privacy

• Minimize data access to only what’s necessary for testing
• Don’t store or share personal data discovered during testing
• Report data exposure vulnerabilities without exploiting them
• Follow GDPR and local data protection laws

DON’Ts – Never Do These

1. Never Test Without Authorization

• Never access systems without explicit permission
• Don’t assume permission – verify scope explicitly
• Never test “out of scope” assets even if you find them
• Don’t exceed authorized access – stay within defined boundaries

Legal risk: CFAA (US) and CMA 1990 (UK) prohibit unauthorized access. Penalties include imprisonment.

2. Never Cause Harm

• Don’t modify or destroy data during testing
• Never create backdoors or permanent access mechanisms
• Don’t disrupt services or availability
• Never exfiltrate data beyond what’s necessary for proof

3. Never Blackmail or Extort

• Never threaten to publish vulnerabilities for payment
• Don’t use vulnerabilities for extortion
• Never demand bounties as condition for not publishing
• Result: Permanent platform ban + potential criminal charges

4. Never Disclose Prematurely

• Don’t publish vulnerability details before remediation
• Never share findings with third parties without permission
• Don’t post proof-of-concept code publicly without coordination
• Never disclose program existence for private programs

5. Never Use Deceptive Practices

• Don’t impersonate authorized security researchers
• Never falsify vulnerability reports or evidence
• Don’t misrepresent your identity or affiliation
• Never submit false reports for rewards

6. Never Violate Privacy Laws

• Don’t access personal data beyond testing scope
• Never store or share PII discovered during testing
• Don’t bypass privacy controls beyond what’s necessary
• Follow GDPR/data protection requirements

Scope Verification Checklist

Before beginning any testing, verify:

• Authorization Document: Written permission to test?
• In-Scope Assets: All authorized targets identified?
• Out-of-Scope Assets: Know what’s explicitly prohibited?
• Testing Methods: Required or prohibited techniques?
• Time Restrictions: Designated testing windows?
• Safe Harbor: Program has and honors safe harbor policies?
• Reporting Channel: Know official vulnerability submission process?
• Disclosure Policy: Understand when/how you can publish findings?

Authorization Types

Authorization Best Practices

• Always get it in writing – verbal authorization is insufficient
• Define scope explicitly – “everything except X” is too vague
• Specify time boundaries – testing windows and deadlines
• Include escalation procedures – what to do if issues arise

Responsible Disclosure Process

1. Validate – Reproduce issue, document PoC, assess severity, check for duplicates
2. Submit – Use official channels, include description + steps + impact + remediation
3. Coordinate – Allow validation time, respond to questions, agree on timeline
4. Verify – Confirm fix applied, test that vulnerability is remediated
5. Disclose – Per agreed terms (coordinated, limited, full, or non-disclosure)

Red Lines – Violation Severity

When to Stop and Escalate

Stop Immediately If:

Escalate When:

• Legal questions – Consult legal counsel
• Disputes – Request platform mediation
• Unresponsive programs – Follow platform escalation procedures
• Criminal activity discovered – Report to authorities
• Safety concerns – Escalate if human safety at risk

Legal Framework Summary

Other jurisdictions: Canada, Australia, Germany, France, Japan have similar laws. Research local laws before international testing.

References: CFAA | CMA | GDPR

Standards Compliance

Platform Quick Reference

Platform Docs: HackerOne | Bugcrowd | Intigriti | YesWeHack

Certifications Reference

References

Platforms: HackerOne Docs | Bugcrowd Docs | Disclose.io

Standards: PTES | OWASP WSTG | NIST SP 800-115

Legal: CFAA | CMA 1990

For detailed reference material, see the references/ directory.