1. HTTPS
2. HSTS
3. CSRF
4. CORS
5. DNSSEC
6. DANE
7. CSP
8. Nonce
9. Security.txt

#HTTPS

The web server can serve your web application over a secured HTTPS connection using a signed SSL certificate. In the earlier days of the internet is wasn't that common like it is today. Make sure your redirecting all your normal HTTP traffic to HTTPS by default, so that every request to your web application gets automatically upgraded and secure. In addition, HSTS can help with this.

#HSTS

The HTTP Strict-Transport-Security (HSTS) response header informs the browser that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS. This setting can be defined at server and web application level using HTTP headers. The setting can be cached heavily by the browser and therefore make your website inaccessible when the HTTPS connection is not configured correctly.

#CSRF

Cross-Site Request Forgery (CSRF) is a protection mechanism for preventing requests being made from outside your application. Typically it is used to prevent all non-GET requests. For possibly destructive actions like POST, PUT and DELETE there is a verification performed by your application that checks a randomly generated token that is attached to the session of the user. Because only the server can retrieve the token correctly and send it with any non-GET request, then the application can be sure that the request is coming from the application itself.

#CORS

Cross-Origin Resource Sharing (CORS) is a protection layer configured in your web server or web application using an HTTP-header that defines an origin other than its own to permit the browser to load resources from. By default browsers block loading resources from external domains using Javascript.

Read more about CORS on MDN

#DNSSEC

Domain Name System Security Extensions (DNSSEC) is a protection layer on top of DNS. It makes sure that the DNS server that is responding to the HTTP client (for example a web browser) is authenticated by the domain authority that keeps a register of the domain in the registry. Therefore the DNSSEC needs to be implemented on the domain registry level and contains settings that need to match the settings in the DNS.

Read more about DNSSEC on SIDN

#DANE

DNS-based Authentication of Named Entities (DANE) is a protocol that only works when DNSSEC is activated.

#CSP

Content Security Policy (CSP) is a protection layer configured in your web server or web application using an HTTP-header that defines what resources are allowed to be loaded by the browser. This can be used to prevent loading resources from external domains or to prevent loading resources that are not using HTTPS.

#Nonce

A nonce is a randomly generated token that should be used only one time for one request to your web application and can be used by Content-Security Policy (CSP).

The nonce can be generated by the web server or the web application and is being sent as HTTP header and inside the HTML. By adding a nonce attribute to <script>, <link>, <style>, <img>, <iframe>, <audio>, <video> or <object> HTML element the browser can verify this with the HTTP header and determine if it can be executed safely.

Read more about nonce on MDN

#Security.txt

When a security risk is discovered in your web application you would likely get to know about it as fast and discretely as possible. It happens often that independent security researchers discover risks on an web service, but they often lack the channels to disclose them properly to the responsible party. As a result security issues may be left unreported and unknown to the owner of the web service. To fix this problem, the standard for security.txt has been created, where security researchers can find the information to communicate and disclose security vulnerabilities securely.

Read more about security.txt