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

When designing your service

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()?
(in)security should be configurable, and default to the more secure option
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
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 service

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

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