This document covers general security guidelines for API endpoints within Brightcove. These guidelines will cover general points like:
- Access control best practices
- Input validation
- Request verification
- Replay attacks
- Logging and Error Management
API endpoints should follow the principle of least privilege. Services with protected information should serve to the smallest group possible.
APIs with misconfigured access controls can lead to unintentional information leaks, or unauthorized and malicious state-changing actions on sensitive data.
A POST that allows the user to modify information on an account without checking if the user owns the account being modified.
A GET request that returns sensitive informative information without authentication.
Determine which API actions should be considered sensitive or public.
For Internal (to Brightcove) APIs: Along with the same steps required for public sensitive APIs, try to also limit network access as much as possible. Ideally, these endpoints should be restricted to a closed network, and require multi-factor authentication or tie-in with our internal SSO provider.
For Public APIs with sensitive information: Require authentication before performing any action being requested. API keys should be both revocable and renewable.
For Public APIs providing public information: Ensure no state changing actions are being performed through a public API without authentication. Consider rate limiting to prevent a single host making too many requests in a small amount of time.
Incorrect access controls can range from High to Low Severity.
Incoming data can be malformed or crafted to cause unintended behavior when it is parsed.
Depending on how input is parsed, it is possible for unvalidated input to contain command injections, or other harmful actions.
Accepting a DELETE request for an API that should only accept GET and PUT requests, causing data to be deleted or malformed in the backend database
Type checking - Ensure input is of the expected data type, reject anything else.
Length and size checking - Input should be within an expected length or size. Reject anything larger or smaller than expected.
Whitelist accepted content-types.
Restrict http methods.
Parsing - Third party parsers should be kept up to date, changes to internal parsers should be carefully reviewed.
Input Validation issues could range from Low to High depending on how the error can be leveraged.
It is possible that a request could be modified in-transit between the original requester and the API endpoint.
Modified requests may cause state changing actions to the original requester’s data, or cause incorrect, modified, or unexpected data to be served.
A JSON Web Token is utilized in a web-application, but does not include an HMAC as the specification requires to pretect token integrity
Utilize TLS for all network requests
Integrate signing of requests, e.g. by using a recommended HMAC algorithm
An attacker sends a previous, genuine request to cause an action to happen again at a later time.
Modified requests in-transit: An attacker modifies data in the genuine request as it is sent.
Some API requests (e.g. login-related requests) are time-sensitive, meaning they are only valid for a specific period of time. Not taking this time restriction into account could allow unauthorized usage or changes to resources.
Include timestamps within signed requests (see above) and deny all requests that are relatively too old.
Depending on what actions the request can take, severity could range from Low to High.
Security practices that are relevant to an application's logging and error management techniques.
Logging is important for ensuring security events are being effectively monitored for, as well an helps with forensics activity, should the need for that ever arise.
Sensitive data can accidentally be exposed via error messages and other outputs.
No logging, or logging that's not verbose enough (or even too verbose).
Returning stack traces or other descriptive information of the service backend.
Ensure that your application is coded and configured to log to our central log repository, as this helps with monitoring and investigations.
Return relatively vague error responses. Put as little information as possible when returning an error to the user. Do not return any configuration data, information about the server environment, or debug information like stack traces.
Ranging from Low to High depending on context.