Security
Overview
As you would expect, Open Banking Access takes security very seriously.
To demonstrate our commitment to security, we check our website is following industry best practices with the following tools:
SSL Labs gives us an "A+"
SecurityHeaders.io gives us an "A+"
HTTP Observatory gives us an "A+", with 125 points.
However, we recognise these tests only cover the basics.
The homepage describes how this system works, and how that process will inherently keep your data secure.
And from a technical point of view, we take these extra steps to be even more confident of that level of security:
To reduce the risk of attack, we only store the information we need.
Any time a person requests information from our website, it checks that they have permission to do so. This includes preventing people from seeing each others data, and stopping basic accounts from being able to access data/features that they should not be able to (privilege escalation).
We always use HTTPS, with a good configuration, to ensure that data is encrypted when it's being sent over the internet.
To ensure that browsers always use an encrypted connection, we use the HTTP Strict Transport Security (HSTS) header.
We do not store passwords in plain text. This is an extra level of defence just in case our database was to be compromised. Instead we use the bcrypt hashing algorithm, so the passwords cannot be identified easily (even with a brute force approach to guess each password).
We enforce a maximum number of login attempts per IP address. Additionally we keep an eye on the failed login attempts when reviewing our access logs.
While we currently don't, any uploaded files (e.g. images) would be put into a folder where code execution is disabled, and images would be re-saved to reduce the risk of these files containing malicious content.
To further protect against someone uploading a file as one type (e.g. an image), and the browser seeing it as another type (e.g. JavaScript), we send the X-Content-Type-Options: nosniff header.
The server automatically applies security patches every day. We realise there is a small risk that a patch may result in the website becoming unavailable, but it ensures that security vulnerabilities are patched as soon as possible.
The server is configured to only run the services needed, with the most restrictions possible. This includes only allowing certain types of connections (limited open ports), server admin login only by authorised SSH Keys (no passwords), accounts having very limited access (file permissions), etc.
All data is sent to our database via a process known as Prepared Statements (or escaping as needed), which protects against SQL Injection. This defends against a type of attack where someone could access or modify the data we store.
All data displayed on the website is encoded appropriately; this is typically done though HTML and URL encoding, which protects against Cross Site Scripting (XSS) attacks.
As an additional layer of defence, we also use a very strict Content Security Policy, where we are proud to not include any of the "unsafe" statements (i.e. we do not use inline JavaScript or CSS). We also have a "default-src" of "none", so we can limit the sources and features we use (typically just our own website).
We set the Referrer Policy to not expose sensitive data from the URL - not that we put any sensitive data in the URL (as that could be found in the access logs).
If you log in to our website, we will generate a session for you, where the unique token is stored in a cookie (query strings are potentially vulnerable to session fixation and information leakage attacks), and we use several other mechanisms to protect against other session based attacks (e.g. changing the token every 5 minutes, and storing a key in the session so we know we generated every token).
Once logged in, we also protect against a kind of attack where a malicious website could cause the victims browser to perform actions on our website (e.g. edit or delete an account). This is known as a Cross Site Request Forgery (CSRF), and we block these malicious requests by setting a random value in a cookie, and repeating that value in every form (so that every request that attempts to modify something, we can check that the values match).
To further protect against CSRF attacks, we are using the SameSite Cookie Attribute, so that malicious requests from other websites do not include certain cookies (depending on the request type, and the cookie).
We set "HttpOnly" and "Secure" attributes on all Cookies, so they are only used on HTTPS connections, and not available to JavaScript (important for the Session Token). We also enforce the Secure attribute by using the "__Host-" name prefix.
And finally, to protect against Click Jacking attacks, we use the "X-Frame-Options" header to either DENY (default) or SAMEORIGIN, and the "frame-ancestors" directive in the CSP header.