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.