Our product exists to address security risks caused by 3rd party scripts. However, since c/side deploys through a third-party script, you might rightfully wonder why you should trust us.
Here’s why:
Script security is our bread and butter. For lots of vendors, serving the script is just a part of their product. We put every care and attention to detail in how we proxy, store and process scripts. We work to cover the blind spots that others might have missed.
Let’s talk about that process.
First of all, employee access has strict 2fa requirements, an approval chain for accessing or updating production environments and a strict automatic sign-out. We follow all modern security practices in securing this environment, for example: we have no static access keys in our entire account. We employ strict least privileged access for all systems, and utilize tooling such as OIDC, right down to the individual container level.
Beyond securing our own infrastructure, there is our product: the work we do to help secure our customers against other vendors' mishaps.
We proxy every script via our servers. This allows us to strictly control what data gets sent upstream to the vendor to fetch the script. The scripts themselves are stored in AWS.
Our proxy converts all traffic to HTTP/2, even if the original scripts are not.
When we fetch a script, we do further processing on related pieces of information regarding that script and where it came from. For example, we look into the history of the domain it was served from, the IPs that it was served from, the certificates it was served with.
We then dig deeper into the specifics of the script. We automatically work through the entire Abstract Syntax Tree (AST), flagging at a huge scale anything we see that may be alarming.
We aggregate this information, along with a vast number of other sources we internally compute, to understand the impact this script could have on your users. We are able to block scripts in an instant when we detect something dangerous enough and can understand the impact of where the script was served.
This is unique in our space.
All of this happens before the script is fetched by the browser, ensuring your users are safe from anything malicious.
There are some other considerations that help make our product even better for your users and your security. For one, we are able to cache scripts, and can decrease the time taken to load that script for your users. This has the benefit of speeding up your site, and for our product to not add any latency.
But we don’t reduce security through caching. We specially rewrite caching headers so that we can block a script and still have it be blocked for customers who might already have it in their cache, while still maintaining caching performance.
Our tool does not capture PII data, input/form-data, innerHTML (strings/texts), or payment data.
On our proxy domain, we employ DNS Security Extensions (DNSSEC) to protect against DNS spoofing attacks. This ensures that the domain name system (DNS) infrastructure is secure, preventing attackers from redirecting traffic intended for c/side.
Resource Public Key Infrastructure (RPKI) then, helps in verifying the authenticity of IP addresses, ensuring that the routes our data travels are legitimate and secure, preventing route hijacking.
It goes without saying that every rose has its thorn. But with script security being our sole focus, we work extra hard to protect data, our processing pipelines and our customers. And with the technology we run, we work to further protect our customers by preventing bad scripts from being served to their users.
We pledge to continuously develop our own security as well as that of our product to keep on pushing the boundaries and create a safer web.
If you want to try c/side, you can get started in minutes.