Security for new services
This page is currently a draft.
|
Security goals promoted by SOA[edit]
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[edit]
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[edit]
- 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