Security for new services

Security goals promoted by SOA
SOA promotes certain security goals within the system. New services should ensure that these are promoted:
 * Least Privilege - the new service should only have access to minimum amount of resources and sensitive information that it needs. E.g., a new service that deals with page content should not have access to user's password hashes.
 * Simplicity - Although both MediaWiki and the new service will have some amount of extra features to integrate, overall the design should be simpler when the feature is brought in as a service, than if the feature had been integrated into "the monolith".

Specific controls
In general, new services that are accessed by end users should implement the following security controls, in addition to the normal architectural and secure coding practices.
 * Require https to access your service if the request or response could contain sensitive information
 * Set standard headers for the response:
 * Set utf8 as the charset
 * Set X-Content-Type-Options:nosniff
 * Set X-Frame-Options:DENY or SAMEORIGIN
 * Set Content Security Policy headers
 * Use mandatory access controls to contain any sub-processes spawned by your service

Most services should not

 * Handle or store data protected by our privacy policy
 * Implement their own authentication - make sure your use case is considered in the SOA Auth RfC, or potentially use OAuth