[SPIKE] Initial Security Investigation

Description

Now that a small set of features have been added to the code base, let's take some time to investigate any security holes that we can find, and implement any security best practises we can find.

Ideally, this would have been performed at the initial requirements gathering stage and will be repeated as we continue to develop the application.

High-Level Proposed Solution

Investigate:
- OWASP Top Ten
- insecure deserialisation issues (See: Alice & Bob Learn Application Security pp 114)
- OWASP recommended security headers
- OWASPHeaders.Core if applicable
- CORS
Ensure that HTTPS redirection is enabled and forced in production
Ensure that any secrets (i.e. API keys, db connection strings) are not hard coded
- Perhaps use app.config or user secrets
Ensure that the developer exception pages are disabled for production
Ensure that the X-Powered-By header is removed in all environments

Considerations

Any changes made to the API, including adding security headers, will likely cause us issues when we integrate with a UI. As the UI has not yet been built, we shouldn't need to worry about that yet. But, it will be useful to have some way of globally disabling any security features (FOR LOCAL DEVELOPMENT ONLY) in a programmatic way. This will enable us to test whether there is something in the security set up which is stopping the UI from working.

Requirements

Investigate the above projects (see High-Level Proposed Solution section)
Produce comments below which outline whether any of them are relevant
Produce a number of GitHub issues for tackling each item which is deemed relevant.

Based on reading both:

It is recommended that the following actions are taken for HTTP-based Rest endpoints:

Forcing both application/json and the text encoding of utf-8
- This has a double whammy:
- application/json prevents the content from being misinterpreted by the consumer
- utf-8 prevents JSON hijacking by forcing a different encoding on the request (such as UTF-16BE)
Remove XSS protection
- Set the X-XSS-Protection header to 0
- See the OWASP secure headers project for why
- tl;dr -> adding X-XSS-Protection with a non-0 value causes other security issues
Set X-Content-Type-Options to nosniff
- This stops a web browser from attempting to guess/sniff the content type, overriding what it was told by the API
- This can help mitigate XSS attacks
Set the X-Frame-Options to deny
- This stops the API responses from being loaded in a frame
- Which prevents drag 'n drop clickjacking
Set the Cache-Control header to no-store
- This stops any API responses from being cached in the browser
- Cached responses could lead to any security-related data from being cached in the browser
Set a very restrictive Content-Security-Policy with the following values:
- default-src set to none
- This prevents the API response from loading any scripts
- frame-ancestors to none
- A belt-and-braces addition for the X-FrameOptions` header value
- sandbox (add this as it's own directive)
- This prevents any scripts or other resources from being executed
Remove the Server header
- This can reveal information about the HTTP server used
- Which could aid in a malicious user utilising known vulnerabilities
If present, remove the X-Powered-By header
- For the same reasons as the Server header

An example of the full set of headers and values is:

content-type: application/jsonl; charset=utf-8
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
X--Frame-Options: deny
Cache-Control: no-store
Content-Security-Policy: default-src 'none'; frame-ancestors 'none'; sandbox

GaProgMan / bookApi