User:CSteipp (WMF)/ServiceSecurity

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

= When designing your service =
 * 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
 * 2) * TODO: should come up with a list of recommended libraries in the to-be-determined standard language list
 * 3) * IN PROGRES: SOA Auth might provide session management-aaS
 * 4) * TODO: Libraryize SVG and CSS sanitization; maybe the entire UploadBase::verifyFile?
 * 5) (in)security should be configurable, and default to the more secure option
 * 6) Be careful about the private data your service exposed
 * 7) * Don't show internal ip's
 * 8) * Sanitize errors / exceptions
 * 9) * User contributed data must be able to be deleted / suppressed
 * 10) ** This might require an authorization framework for adminstrators / oversighters
 * 11) Use libraries supported by a security team, that has released security updates
 * 12) * Ensure someone on your team is alerted to security issues
 * 13) * Have a documented process for releasing security updates to your service to third parties
 * 14) ** We should try to have a standard process across the organization

= When implementing your service =
 * 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 service =
 * 1) Service endpoints and parameters need to be discoverable so we can setup automated, dynamic security scanning