Adding the HTTP response header and DNS TXT records
Setting up report headers and txt records is easy and can be done in just a few minutes. While some of them only instruct to send reports, others can enforce a policy that can leave your website or mail server inaccessible when configured incorrectly. We recommend that you do your own research before enforcing policies. To get you started, we are going to help you implement those that send reports only so you can get started immediately and without risk.
If you don't know how to add records to your DNS or how to add a HTTP response header to your site's configuration see this page.
If you haven't done so already, sign up and create a URIports account and choose a subdomain to create your personal report endpoint. When adding the policies below, don't forget to change the example to your personal report URI.
Let's start by adding the "Report-To" header to instructs the user agent to send "Crash", "Deprecation" and "Intervention" reports to your URIports account. The endpoint configured in this header can be used for the delivery of "Network-Error-Logging", "Content Security Policy", "Cross-Origin-Embedder-Policy", "Cross-Origin-Opener-Policy" and "Permissions Policy Violation" reports too. We'll get to those in a minute.
To enable the Reporting API you need to add the following HTTP response header to your site configuration.
While you're at it, add Network-Error-Logging (NEL) as well. This will instruct browsers to also send reports about networks errors using the Report-To header defined above. If you have a high traffic website, it might be a good idea to lower the "failure_fraction" to define a sampling rate. The value must be a number between 0.0 and 1.0 inclusive (e.g. 0.05 for 5%).
Content Security Policy
After that, the Content Security Policy (CSP). This HTTP response header has both a "report only" and "enforce" variation. We'll get you started by adding the "report only" version. This will instruct browsers to send reports whenever a violation is triggered. By adding the following header you will instruct the user agents to only allow content from the domain itself ('self'). Other sources will be logged and reported. This will give you great insight in what content sources are used while browsing your site. You can then add the sources you want to allow to your CSP policy. Over time, when you are content with your policy, you can enforce it by changing the header name from "Content-Security-Policy-Report-Only" to "Content-Security-Policy" and adjust the report-uri to "/reports/enforce".
But for now we only want to enable logging. We do this by adding the following header:
Content-Security-Policy-Report-Only: default-src 'self'; font-src 'self'; img-src 'self'; script-src 'self'; style-src 'self'; report-uri https://example.uriports.com/reports/report; report-to default
WARNING: Keep in mind that adding a CSP to a high traffic website with missing sources could result in a lot of violations and reports. This could exhaust your quota within a few minutes. Be careful and omit the 'report-uri' and 'report-to' directives from the CSP and monitor the 'Developer Tools' console (F12) inside your web browser while browsing your website. Add all legit violated sources to you CSP until there are none left. After that you can add the 'report-uri' and 'report-to' directives to instruct browsers to send the violation reports to us.
The Expect-CT header allows you to instruct user agents to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to your host. This allows you to discover misconfigurations in the Certificate Transparency deployments and ensures that misissued certificates accepted by UAs are discoverable in Certificate Transparency logs. If you want to enforce this policy add the valueless "enforce" directive to your policy and adjust the report-uri to "/reports/enforce"
The Permissions Policy (previously known as Feature Policy) specification defines a mechanism that allows developers to selectively enable and disable use of various browser features and APIs. A report is sent, using the Reporting API defined above, whenever a violation is triggered. There is no "disallow all" function, so you need to configure an allow list for each feature you want to allow or disallow. "microphone", "camera", "fullscreen" and "payment" are a few of the more common features that can be added to your policy. A complete list of available features and their definitions can be found here.
This specification is still in draft and in a very early stage of development. Because there is no 'Report-Only' option (yet), we do not recommend using this header in production.
If you do want to implement this header, please adjust the permissions and allow list origin(s) to your liking.
Permissions-Policy: microphone=(), camera=(self "https://ww.example.com"), fullscreen=*, payment=self
COOP / COEP
Some web APIs increase the risk of side-channel attacks like Spectre. To mitigate that risk, browsers offer an opt-in-based isolated environment called 'cross-origin isolated'. Use Cross-Origin Opener Policy (COOP) and Cross-Origin Embedder Policy (COEP) to set this up for your website.
The COOP HTTP response header allows you to ensure a top-level document does not share a browsing context group with cross-origin documents. The COEP HTTP response header prevents a document from loading any cross-origin resources that don't explicitly grant the document permission (using CORP or CORS).
By enabling the 'Report-Only' version of this header, you will get reports of violations triggered by your site visitors without actually breaking anything. These violation reports can be of great help in implementing these headers. Make sure you have set up the Reporting API to specify a destination for the reports.
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="default"
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="default"
If you haven't implemented SPF or DKIM yet, get to it right away! Sender Policy Framework (SPF) is a security mechanism created to prevent others from sending emails on your behalf. The DomainKeys Identified Mail (DKIM) standard has been created for the same reason. It signs your emails in a way that will allow the recipient’s server to check if the sender was really you and if the message was altered during transfer.
If you already have SPF and DKIM in place, you can add DMARC to your DNS records to start receiving both failure (forensic) and aggregate reports from receiving mail servers. It will give you great insight in the amount of fake emails that are being sent on your behalf. You can also use DMARC to instruct a receiving server what to do when both DKIM and SPF fail. For now, we just want the reports. We do this by adding the following TXT record to your DNS records:
"v=DMARC1; p=none; rua=mailto:firstname.lastname@example.org; ruf=mailto:email@example.com; fo=1:d:s"
SMTP TLS Reporting
We are almost done! Last one on our list is SMTP TLS Reporting (TLS-RPT). A reporting mechanism by which sending systems can share statistics and specific information about potential failures with recipient SMTP MTA (STARTTLS, DANE TLSA and MTA-STS). You can then use this information to both detect potential attacks and diagnose unintentional misconfigurations. You need to set up a DANE TLSA DNS record and/or deploy a MTA-STS policy for this to work.
Add the following TXT record to your DNS:
VALUE: "v=TLSRPTv1; rua=mailto:firstname.lastname@example.org"
That's it! You're done! Now we wait for all those reports to come in. This will give you some time to read more about the different types of reporting mechanisms we installed. If you are confident enough you can change or add some header values to enforce your policies to improve your website and mail security.