Security Auditing Your Website

One of the goals of Pillser is to become HIPAA compliant. In short, HIPAA is a set of national standards that govern the privacy and security of individuals' health information. The compliance involves assessment of the security, privacy, and administrative safeguards. It's complicated and time-consuming, and if I've learned anything from my experience dealing with similar security standards (like PCI-DSS and SOC-2), it is that the more self-auditing you do, the more you can simplify the cost and effort of compliance when a third-party is involved.

This post is focused on the security aspect of Pillser, specifically, the automated checklists that anyone can use to assess their own website's security. It is not meant to be a comprehensive security audit, but rather the lowest hanging fruit that you need to clear before diving deeper into the more complex aspects of security.

Headers

Perhaps the simplest item on the checklist is to ensure that your website has proper HTTP headers.

A few tools that can help you with this:

• https://securityheaders.com/
• https://developer.mozilla.org/en-US/observatory/

Tools like SecurityHeaders.com and Mozilla's Observatory scan your website to identify any missing security headers.

Both audits have a brief explanation of what the headers do and why they are important.

Content Security Policy (CSP)

content-security-policy header was arguably the hardest to implement (particularly nonce). It is a policy that allows you to define what resources can be loaded on your website. This is important because it prevents malicious scripts from being injected on your website. For Pillser, it was important because we host user generated content (e.g., Ask AI, reviews, etc.). We wanted to make sure that even if a user was able to successfully inject malicious code, we would be able to detect it, block it, and remove it.

To my surprise, implementing CSP identified that Cloudflare was injecting a script into our website. This script (which is not malicious) was injected by Cloudflare to obfuscate email addresses. It is not something that we have a use case for, so we decided to remove it. However, this issue report turned out to be a good validation of the value of CSP.

DNSSEC

DNSSEC is a standard that specifies how to validate the DNS records of a domain. Implementing DNSSEC is important because it ensures that DNS queries are not spoofed.

To check if DNSSEC is enabled, you can use the DNSSEC debugger.

Email Security

Email is a critical part of our business. We use it to communicate with our customers, share information about our products, and to send out newsletters.

To ensure that our email sender cannot be spoofed, we implemented SPF and DKIM. SPF is a standard that specifies how to validate the sender of an email, while DKIM specifies how to validate the domain of an email.

We are using Cloudflare's DMARC Management to understand if messages sent from our domain are passing DMARC authentication, DomainKeys Identified Mail (DKIM) authentication, and Sender Policy Framework (SPF) policies.

Outside of Cloudflare, you may also try MXToolbox, which is a free tool to (among other things) check DMARC records.

SSL Server Test

The SSL auditing tools ensure that your website is serving over HTTPS and using secure ciphers. The SSL is necessary to prevent man-in-the-middle attacks.

For this audit, we used SSL Labs. It is a free service that performs a series of tests on your website to ensure that it is secure.

Because we are using Cloudflare, we expected to pass with flying colors. However, SSL test identified that we were allowing deprecated ciphers. If you are using Cloudflare, you may want to set the Minimum TLS Version to 1.3. Use a tool like caniuse.com to determine what percentage of your visitors support TLS 1.3.

HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is a security feature that informs browsers that the site can only be accessed using HTTPS. This is more secure than simply configuring a HTTP-to-HTTPS (301) redirect on your server, where the initial HTTP connection is still vulnerable to a man-in-the-middle attack.

To implement HSTS, you need to add the Strict-Transport-Security header to your website, e.g. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. When the browser receives this header, it will remember that the current domain should only be accessed over HTTPS, i.e. even if user types http://pillser.com in the address bar, the browser will automatically redirect to https://pillser.com.

As an extra layer of precaution, you can also opt-in to preloading the HSTS list. This is a list of domains that are known to support HSTS. If you are a site owner, you can submit your domain to the list at https://hstspreload.org.

Technology Lookup

The next audit is to identify what technologies are being used on your website, as identified based on clues like the presence of specific scripts, headers, cookies, and other indicators. The goal is to reduce the attack surface by limiting the information about your technology stack.

To perform this audit, you can use Wappalyzer. It is a free tool that identifies the technologies used on your website.

Domain Expiry

Use a tool like What's My DNS? to determine the expiry date of your domain.

We keep our domain's expiration date set to 5 years in the future. This is to ensure that we do not accidentally expire our domain, which could become a security risk.

Security.txt

security.txt is a standard that specifies how to disclose security contact information. It is a file that lives at the root of your website, e.g. https://pillser.com/.well-known/security.txt.

We use security.txt to disclose our security contact information.

Application-Level Security Audit

Last but not least, we perform an application-level security audit. This is an autonomous process that attempts to identify known vulnerabilities in the application. It relies on recognizing patterns in the application (e.g. sign up form, login form, etc.), and then attempts to exploit those patterns by submitting malicious requests.

There are many tools available for this, e.g. Burp Suite, ZAP, etc. We've evaluated a few and found Probely to be the most comprehensive. They have a trial, so your first few scans will be free. After each scan, you will get a report that includes a list of all findings and a recommendation on how to fix them. You will also get a PCI-DSS and OWASP compliance report.

A few things to consider before performing an application-level security audit:

• Consider if you want to disable Sentry for the duration of the audit. This is because errors triggered by malformed requests might exhaust your monthly limits.
• Consider what forms might trigger side-effects. For example, if you have forms that send emails, consider how you want to handle those if there is a sudden spike in attempts to submit those forms.

Closing Thoughts

Security is not about setting it and forgetting it. For example, this post is written based on my notes from over a month ago. I was surprised to see that recent changes caused minor regressions, and used the opportunity to reapply the necessary security measures. In large part, this post is a reminder to myself of the regular audits that we need to do to ensure that our website is secure.

This post is the first in a series of posts that will cover the security and compliance aspects of Pillser. In the future, we will cover internal audits, dependency management, and other security measures. We will also cover the best practices for security and privacy at the application-level, such as automatic logoff, encryption, event logging, etc. Join our Discord server if you are interested in learning more.