존 미치

December 20, 2023 — 5 min read

Blockchain technology and web3 have seen tremendous innovation and development over the past decade. However, we still need to work within a web2 model and with technologies built for web2. This makes for some challenging problems, especially security.

A web3 application runs code in a browser where that code is exposed to the public. This makes it easy for blockchain endpoints used in that code to be exploited. Quicknode’s Endpoint Armor allows you to rate-limit and reduce the attack surface of an endpoint, tailoring it to your application, and making it more secure and less attractive to malicious users.

The web2 model

Typically in web2, you have users with individual permissions. This means the user can only access or modify their data. For example, if you log into instagram, you can’t post photos as someone else, you can only post as yourself.

This means the code and network calls exposed on the browser will typically only let you as a user do what you could do on the website. A malicious actor visiting the website will not see code or network calls letting them do anything because they are not logged in. A logged-in user will only see code and network calls that allow them to do what they are allowed to do.

This setup, which we have used on the web for decades, makes it very hard to do anything malicious unless you know someone’s password or credentials.

The web3 model

In web3, things are different. There typically aren’t traditional web2 users and the server is often the blockchain itself. The user can visit a web3 website and perform actions on the blockchain, often directly calling the blockchain itself from front-end code.

This creates a problem, without a concept of users and permissions, anyone can take that endpoint URL and start making calls to the blockchain with your endpoint.

Current solutions

Currently, web3 developers have some solutions to prevent this. One is to put the endpoint behind a proxy, usually a backend server that wraps the calls to the blockchain. Backend code is not exposed in a browser, so this allows the endpoint URL to be securely hidden and authentication methods set up. However, without the concept of traditional users with permissions, this still can leave the backend proxy exposed to abuse. Additionally, this is a lot of work to set up.

There are also third-party services to prevent spam and abuse that are often used in conjunction with a blockchain endpoint URL. These can be costly, will sometimes limit legitimate users, and are not tailored to blockchain usage.

There are already some basic settings to prevent abuse, currently Quicknode offers JWT authorization, and referrer, IP, and smart contract whitelisting configurable an endpoint’s security settings. These can be very powerful, especially when used together and proxied with a custom backend or third-party service. However, if your endpoint URL is exposed on front-end code, there is still a chance a malicious actor can emulate these calls by spoofing request data.

Entering Endpoint Armor

Endpoint Armor, a Quicknode marketplace add-on, takes the approach of treating your publicly-exposed endpoint URL as well… public. The endpoint URL and network calls are going to be exposed in a browser so let’s make the endpoint as limited and tailored to your specific application’s needs as possible.

This limiting is done with the combination of the following approaches. You are provided with a secure URL that you can use in your application. This URL is limited in access based on your specific configuration.

For more details and configuration examples, please see the How to Secure Your Endpoint Using Endpoint Armor guide.

Global Rate limiting

Endpoint armor allows you to rate limit your endpoint by seconds, minutes, and/or hourly rates. This will limit the amount a malicious user can query your endpoint but still allow for typical usage.

Visitor Rate limiting

Endpoint Armor allows you to set rate limits per unique visitor to your website. This means unique visitors to your website will have their own individual rate-limit. This approach scales well since your visitors can increase and each individual user will be rate limited the same way.

Method allowlisting

Endpoint Armor requires you to specify what RPC methods are allowed on your endpoint. This approach drastically reduces the attack surface for a malicious user. Often, web3 websites will only use a handful of RPC methods. Leaving the rest of them exposed is leaving a lot of exposed area for a malicious user to exploit.

Method rate limits

Rate limits can also be set for individual methods, allowing for very granular limiting based on your application’s needs.

Method specific limiting

Often, an application will just need to interact with a specific smart contract or the latest blocks in a blockchain. Endpoint Armor allows you to limit these parameters for certain methods. For example, on EVM-compatible chains you can set eth_getLogs to only be able to query a range of the latest blocks. This further limits the area a malicious actor can exploit.

Conclusion

Endpoint Armor allows you to set a robust configuration that can be flexible to your needs. With configuration you can limit exploitable surface area of your endpoint and set rate limits, allowing your Quicknode endpoint to be used in front-end code more safely.

Endpoint Armor is available on the Quicknode marketplace as an add-on for all RPC-based chains. Please see the guide and documentation for a full overview as well.

Sleep easy at night with Endpoint Armor!