Since the OOAPI Gateway will be channeling sensitive information to users over the public Internet, we must make sure the implementation will stay secure.
The provided configuration and code base must use in-flight encryption to protect users from eavesdropping by third parties.
Strategy: the standard configurations provided will have TLS encryption configured for all connections to external services and for incoming connections from clients. Non-encrypted incoming connections will not be accepted.
Since we don’t want to modify the Express Gateway code base
directly (see Updating Dependencies), this will need to be done via
the standard configuration mechanism. Comments warning against
changing the relevant settings will be included in the configuration
as close as possible to those settings.
We will need to update the dependencies regularly to help patch the system against known issues.
Strategy: avoid modifying dependencies down-stream. Use dependencies as provided. Only fork code bases temporarily, when changes will be integrated up-stream in a later release.
In practice this means that Express Gateway is included as a
normal dependency in ../package.json, that ../package-lock.json is
used to specify exact versions of all dependencies and we do not
include node_modules in the repository.
All OOAPI Gateway specific functionality is implemented using standard Express Gateway extension points (custom policies and configuration of standard mechanisms).
The gateway logs should never include personally identifiable information or authentication data. Assume logs can persist for a long time and will be copied to different machines for auditing and debugging. It’s hard to guarantee privacy for logs, so assume logs are not private.
Strategy: be explicit about what will be logged.
Request/response logging: never log a full request or response; do not log request or response bodies, do not log authentication tokens, user names, passwords, tokens or other credentials. Explicitly specify headers and other data to be logged (use allow-lists, not deny-lists). Do not relax these constraints when logging failed attempts at authentication.
Configuration logging: never log credentials from the configuration.
A buggy caching algorithm can leak information between users. The best way to prevent bugs is to make the code base simpler and smaller.
Strategy: cache as little as possible.
Response caching: because some information returned can be personal, do not cache responses or response content to avoid returning personalized data to the wrong users.
Temporary authentication tokens: OAuth and Open ID Connect use temporary tokens for authentication. When using these authentication mechanisms for authenticating the gateway against the backend services, the temporary tokens should be cached to prevent overloading the identity providers. Code dealing with these caches must be reviewed strictly and have extensive automated tests.
All requests will be validated according to the Open Onderwijs API
Specification. When a request body is present the request content
type must be application/json
Currently we only accept GET requests (no request body).
Clients will get access to a set of endpoints (urls and http methods), controlled with an ACL will be configurable in location to be determined.
Currently we only accept GET requests.
SURF has the following list of required headers for HTTP responses. These will be enforced by the gateway using the configuration in ../config/gateway.config.yml. The integration tests in ../test/headers.integration.test.js will check this.
X-XSS-Protection1; mode-blockStrict-Transport-Securitymax-age=31536000; includeSubDomains; preloadX-Frame-OptionsSAMEORIGINX-Content-Type-OptionsnosniffContent-Security-Policy- ~default-src ‘self’~
Access-Control-Allow-Origin*.surf.nlReferrer-Policyno-referrer-when-downgrade