Skip to content

Finding titles

🎯 Goal

Good finding titles help both technical and non-technical readers quickly understand why they should care.

In practice, strong titles usually combine:

  • What? ("Admin takeover...")
  • Who? ("...by unauthenticated users...")
  • How? ("...(stored XSS)")

Examples of good finding titles

  • ✅ "Admin takeover by authenticated users (stored XSS)"
  • ✅ "Leak of database password by config file disclosure (Path Traversal)"
  • ✅ "Read-write access to hiring database (authenticated SQLi)"
  • ✅ "Public configuration file reveals application settings"

Quick rules of thumb ✅

  • Name the impact
    • E.g., "Account takeover", "Read-access to user database"
  • Name who can do it
    • E.g., "Unauthenticated users", "Customer users", "Backend administrators"
  • Name the cause for technical readers
    • E.g., "...via stored XSS", "...(SQLi)".
  • Prefer concreteness over vague categories.
    • E.g., "Public configuration file" instead of "Information disclosure"
  • Choose the most severe verified impact when multiple are possible.
    • E.g., "Account takeover due to password change via CSRF", even if there are other, less severe CSRF vulnerabilities.
  • Keep it concise, but prefer a clear two-line title over a meaningless one-liner.
  • Write in sentence case (not title case)
  • Sometimes, we'll not be able to write a perfect title with all desired information.
    • We live with it.

Bad finding titles (and better alternatives)

  • 🚫 "Cross-site scripting (XSS)"
    • It doesn’t communicate criticality, business/technical impact, and precondition.
    • For readers who don’t know the term, it’s close to meaningless.
  • 🟠 "Account takeover of administrator accounts by unprivileged authenticated users"
    • Better because it is impact-focused.
    • Missing the technical root cause.
      • Readers must guess whether the takeover is due to weak passwords, authorization issues, HTTP request smuggling, XSS, etc.
    • Length will cause a line break.
  • ✅ "Admin takeover by authenticated users (stored XSS)"
    • Covers impact, precondition, technical root cause.

 

  • 🚫 "Command injection"
  • ✅ "Full server compromise by command injection"

 

  • 🚫 "Remote code execution"
  • ✅ "Server takeover by remote code execution (RCE)"

 

  • 🚫 "Path traversal"
    • The impact can vary widely; the title should reflect what it enables in your case.
  • ✅ "Server takeover due to write access to arbitrary files (path traversal)"
  • ✅ "Leak of database password by config file disclosure (path traversal)"
  • ✅ "Disclosure of server files via path traversal"
    • More generic without a concrete impact (which happens in real life)

 

  • 🚫 "Upload of malicious files"
  • 🚫 "Unrestricted file upload"
    • Readers don't know whether this enables server compromise, unauthenticated uploads, or only missing malware scanning.
  • ✅ "Full server compromise by arbitrary file upload (RCE)"
  • ✅ "File upload by unauthenticated users"
  • ✅ "Missing malware check for uploaded files" (though we usually wouldn't report this)

 

  • 🚫 "Read-write access to database"
    • Missing technical root cause.
    • "Database" might be too abstract for non-technical users.
  • ✅ "Read-write access to hiring database (authenticated SQLi)"
  • ✅ "Read-write access to MS Dynamics database (unauthenticated SQLi)"

 

  • 🚫 Disclosure of internal information
    • It’s unclear what information is exposed, so readers can’t assess urgency.
  • ✅ "Public configuration file reveals application settings"
  • ✅ "Disclosure of error messages and stack traces"
  • ✅ "Directory listing discloses existing files"
  • ✅ "Disclosure of server software versions via HTTP headers"

 

  • 🚫 "Cross-site request forgery (CSRF)"
    • Impact ranges from negligible to critical.
  • ✅ "Account takeover via third party websites (CSRF to self-XSS)"
  • ✅ "Forum posts on behalf of other users via CSRF"
  • ✅ "Deactivation of other users’ multi-factor authentication (CSRF)"

 

  • 🚫 "Weaknesses in session management"
    • Hides the actual flaw; readers don’t know what must be fixed.
    • Could still be used in for a finding that includes multiple low-risk findings
  • ✅ "User sessions never expire"
  • ✅ "Logout does not invalidate user session"
  • ✅ "Session token not renewed after login (session fixation)"

 

  • 🚫 "Insecure communication"
  • 🚫 "Weak SSL settings"
  • 🚫 "SSL/TLS misconfigurations"
  • 🚫 "Unkown certificate authority"
    • They don’t tell readers whether the problem is certificates, ciphers, configuration, or a specific vulnerability.
    • Might refer to data in transit (more likely) or data at rest.
  • ✅ "Weak TLS setup might impact encryption in transit"
  • ✅ "Heartbleed vulnerability might allow web application takeover"

 

  • 🚫 "Vertical privilege escalation"
    • "Vertical" is an uncommon attribute in this context: It’s not understandable immediately.
    • It doesn’t specify which role can escalate to which role.
  • ✅ "Trial users gain access to paid features"
  • ✅ "User escalates privileges to admin level"
  • ✅ "Organization admin can compromise other organizations"
  • ✅ "Global reader can write tenant attributes"

 

  • 🚫 "Reputation loss by public configuration file"
  • 🚫 "Compliance non-conformance by reflected XSS"
    • We are not in the position to evaluate business risks that go beyond our testing scope.
    • Reputation loss and compliance issues must be evaluated by the business owners, not us.
  • ✅ "Customer account takeover by authenticated shop users (reflected XSS)"
    • This title includes the application risk/impact.
    • It doesn't go beyond our pentesting scope.