User:CSteipp (WMF)/ServiceSecurity

Some of this will change based on the outcome of the SOA Auth RFC

When designing your serviceEdit

  1. Use libraries that support parameterizing / sanitation (if sqli/shell is really needed); also for session management if state is needed; html templating and sanitization
    • TODO: <someone> should come up with a list of recommended libraries in the to-be-determined standard language list
    • IN PROGRES: SOA Auth might provide session management-aaS
    • TODO: Libraryize SVG and CSS sanitization; maybe the entire UploadBase::verifyFile()?
  2. (in)security should be configurable, and default to the more secure option
  3. Be careful about the private data your service exposed
    • Don't show internal ip's
    • Sanitize errors / exceptions
    • User contributed data must be able to be deleted / suppressed
      • This might require an authorization framework for adminstrators / oversighters
  4. Use libraries supported by a security team, that has released security updates
    • Ensure someone on your team is alerted to security issues
    • Have a documented process for releasing security updates to your service to third parties
      • We should try to have a standard process across the organization

When implementing your serviceEdit

  1. Use headers that prevent XSS: utf8 content-type, no-sniff, restrictive Content Security Policy
  2. Be cautious about direct object references / serialization (use JSON)
  3. Prevent CSRF on all state-changing requests
  4. Prevent directory traversal attacks
  5. Don't proxy requests, or whitelist URLs when you need to
  6. Prevent open-redirects / javascript url XSS vectors
  7. Prevent XXE attacks when processign XML

When deploying your serviceEdit

  1. Service endpoints and parameters need to be discoverable so we can setup automated, dynamic security scanning