The Human Verification Engine consists of two major components:
- 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
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?
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 the solutions 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 a 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 helps 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 scrape input submitted by a user * Action appear to occur because of an end-user when really it was an action 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?
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.
Subresource Integrity (SRI)
SRI is a security feature of modern browsers that enables browsers to verify the integrity of a requested resource.
<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 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.
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 Searching, Shopping, Socializing and Streaming providers globally many of whom choose not to implement such practices and instead rely on HUMAN's proven track record as a trusted AppSec provider with mature practices in all elements of AppSec and DevSecOps practice.
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
For example purposes, we'll say we chose
Given this example, the domain to CNAME would be:
Create DNS Records
The detection tag utilizes several subdomains. You should create the following records:
|Client Domain||→||System Domain|
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.
Once the DNS records have been setup and propagated, our team will purchase an SSL certificate on the domain.