CNAME

Background

The HUMAN Verification Engine consists of two major components:

  • Our HUMAN client-side JavaScript - which observes human and bot interactions with a device and its browser.
  • Our HUMAN server-to-server API - which facilitates delivery of a decision based on gathered device, browser and user interactions (signal).

When a user requests an interface page or SPA client runtime from your application server, HUMAN's client-side runtime tag is appended to the HTML response <head>. The client-side runtime subsequently places a request to retrieve our JavaScript content and add it to the executing client-side runtime. The initial request to retrieve this JavaScript content plays a role in helping HUMAN identify characteristics of the device requesting the content. Furthermore, the retrieved client-side JavaScript retrieves additional content resources (e.g. image files) which help in the activities which validate that a connected web browser's capabilities match those it claims it has via its submitted User-Agent.

Direct communication with a site visitor's device and browser plays an important role in the early stages of gathering HUMAN Signal to identify legitimate users. Given the critical nature of this JavaScript reaching and executing within a site visitor's browser, HUMAN takes proactive action to ensure this step occurs seamlessly 100% of the time.

Why are CNAMEs useful?

CNAME (Canonical Name Record or Alias Record) is a type of resource record in the Domain Name System (DNS) that specifies that one domain is an alias of another canonical domain. We highly recommend that our clients and partners CNAME the HUMAN Tag to obfuscate it and to provide an additional layer of defense against potential malicious actors.

CNAMEs ensure that site visitor browser traffic appears to traverse directly through your domain and not a domain managed by HUMAN (often referred to as third-party in a technical sense). Popular tools like uBlock Origin limit communication between a site-visitor's browser and third-party domains. While HUMAN takes special effort to monitor, coordinate with and adapt to modifications made by such tools' block lists, it is quite common for many of the worlds largest sites and powerful tools to find themselves obstructed by these lists.

CNAMEs also allow you to optionally leverage HUMAN's first-party cookie for improved bot identification. Furthermore by using a customer CNAME, it is harder for adversarial bad actors to identify the HUMAN tag as a 3rd party tag.

How do CNAMEs help resolve Third-Party obstruction?

CNAMEs give the HUMAN JavaScript tag the appearance of coming from your domain, alleviating a majority of the concern associated with block lists present in tools like uBlock Origin. HUMAN infrastructure continues to respond to the tag request (allowing us to witness this JavaScript's retrieval and begin the process of collecting information about the site visitors connected device/browser). The likelihood of a sub-domain CNAMEd within the scope of your own domain being blocked by a browser extension like uBlock Origin is very low because ad blocking tools struggle to differentiate between resources that are necessary to your site's runtime capabilities and those specific to other embedded technologies. For example, a script hosted at scripts.humansecurity.com/human.js that has a CNAME to scripts.yourdomain.com/humanjs will appear, from a site visitor's browser, to come from a sub-domain of "yourdomain.com".

What challenges do third-party script delivery and CNAMEs present and how does HUMAN overcome these challenges?

CNAMEs are often the responsibility of the domain management team responsible for defending an application and might fall within the responsibilities of your AppSec or AppDev team. As such, adding and managing a CNAME might lead to change management hurdles which slow the adoption of HUMAN's solution, raise questions pertaining to the solution's purpose and architecture, and raise perceptions of risk around trust afforded to a "third-party" domain in your site.

  • HUMAN alternatively supports the use of a secondary domain name CNAMEd but owned by your organization.
  • Additionally, HUMAN offers domains managed by our team and monitored against block lists on common browser extensions.
  • Often, during a PoV roll-out it makes sense to use a domain provided by HUMAN, and later you can move toward an effective CNAME'ing practice as you transition to long-term production.

HUMAN offers CNAME complimentary CSP and SRI implementation directives which, when implemented, prevent scenarios where a HUMAN embedded script might impact client-side runtime in a dangerous way. You can find more information about CSP and SRI below.

Content Security Policy (CSP) directives?

CSP directives are an added layer of security that help detect and protect from certain types of client-side runtime attacks such as:

  • A runtime might be used to manipulate users into thinking they should take some unintended action.
  • A runtime witnesses and scrapes input submitted by a user.
  • Actions appear to occur because of an end-user when really it was actions taken by a malicious script.

CSP directives are an important part of ensuring that both first and third party scripts have a limited scope of actions they can take within a site visitor's client-side runtime. For example, an included third-party script could inject actions into a client's browser which ask a user to input their password (when they are already logged in) OR could be used to passively witness and scrape submitted information as the user executes legitimate requests from within your application.

CSP directives restrict where a client-side runtime can make requests, and what scripts inserted into the client-side runtime can do within that runtime.

What challenges do CSP directives present and how does HUMAN overcome such challenges?

CSP Directives implemented without additions to facilitate HUMAN's script runtime limit the scope of what devices and browsers we can evaluate. A site that employs CSP directives but has not made additions to facilitate HUMAN's JavaScript runtime limits HUMAN's ability to identify bots and humans.

HUMAN offers CSP directives that enable us to run properly while ensuring no risk exposure that allows for other included "third-party" scripts to abuse your client side runtime.

CSP Directives when paired properly with CNAME'ing and SRI practices limit the scope of risk incurred by your organization while including HUMAN's JavaScript on your site.

Subresource Integrity (SRI)

SRI is a security feature of modern browsers that enables browsers to verify the integrity of a requested resource.

SRI hashing allows customers to associate a hash with a referenced external resource, establishing a chain of trust. For the referenced resource to load, the cryptographic hash of the retrieved contents must match the one associated with the tag in the page. In essence, SRI hashing institutes a rule by which a HUMAN customer's infrastructure can ensure the agreed upon contents of HUMAN's referenced third-party JavaScript can not change without the customer approval. Only the customer can replace the referenced hash in the <script> tag.

<script src="https://example.com/example-framework.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        Crossorigin="anonymous"></script>

What challenge does implementing SRI hashing present and how does HUMAN overcome any such challenges?

SRI Hashing limits HUMAN's agility in updating the logic through which we observe site visitor devices/browser interactions to differentiate between humans and bots. If a new browser feature or function is released or in rare cases a critical browser patch alters how a device responds to a certain JavaScript exercise, adjusting HUMAN's code to accommodate this change involves coordination between HUMAN's customer team and a site development team who can change an embedded hash.

SRI Hashing in combination with high-level feature reviews offered by the HUMAN team allows some of HUMAN's customers to feel more comfortable placing code they have approved on their site.

HUMAN offers SRI hashing capabilities for our referenced JavaScript payloads and can provide overviews of how our platform is tested and maintained to ensure our code is safe and functions as expected to defend your site from bots.

SRI Hashing when used in combination with CNAME'ing practices and CSP directives serve as a great way to control scope and limit risk in the inclusion of HUMAN as a "third-party" resource within your site. With that said, HUMAN is a trusted AppSec solution provider implemented across the largest Search, Shopping, Social and Streaming providers globally - many of whom choose not to implement such practices and instead rely on HUMAN's proven track record with mature practices in all elements of AppSec and DevSecOps practice.

CNAME Instructions

The below instructions detail how to CNAME a subdomain of your choice against one of our system domains which serves the Tag.

Pick A Subdomain

Let's say your platform or site is on example.com. Choose a subdomain that will be used to point at our system domain. Choose something generic, or unintelligible. E.g. sky, xad, north

For example purposes, we'll say we chose sky.

Given this example, the domain to CNAME would be: sky.example.com.

Create DNS Records

The detection tag utilizes several subdomains. You should create the following records:

Client Domain → System Domain
o.sky.example.com → o.wodomain.com
p.sky.example.com → p.wodomain.com
post.sky.example.com → post.wodomain.com
s.sky.example.com → s.wodomain.com
t.sky.example.com → t.wodomain.com
u.sky.example.com → u.wodomain.com
sky.example.com → wodomain.com

In the example above the system domain is wodomain.com. However a different one will be provided to you by our team or via dashboard.

SSL Certificate

Once the DNS records have been setup and propagated, our team will purchase an SSL certificate on the domain.