While it’s undeniable that cross-chain is critical for unlocking exponential innovation in Web3, it also introduces a potential attack vector for malicious actors. In the software industry, many developers subscribe to the motto “move fast and break things.” But when it comes to cross-chain security and the safety of billions—and eventually trillions—in user funds, the opposite is true: If you move too fast, things break.

What Are Cross-Chain Bridges?

Cross-chain bridges are a type of decentralized application that facilitates the transfer of assets from one blockchain to another. 

Today, cross-chain bridges vary significantly in design and purpose. Some bridges, for example, are specifically built to facilitate transfers between a layer 2 and its respective base chain. General-purpose bridges, such as the ones built on top of Chainlink CCIP, are built to enable seamless asset and message transfers between a wide variety of blockchains. 

Cross-chain bridges are a core piece of Web3 infrastructure. For users, cross-chain bridges enable seamless movements of tokens and messages between chains. For developers, cross-chain protocols represent an opportunity to build chain-agnostic experiences that abstract away infrastructural complexities. And with 6B+ in monthly volume across all cross-chain bridges, it’s clear that cross-chain is a necessary—and widely adopted—part of the Web3 ecosystem.

That’s why if you’re a user, developer, or institution looking to go cross-chain, it’s imperative that you understand these seven key cross-chain bridge vulnerabilities to keep yourself, your users, and your stakeholders secure.  

1. Unsecure Private Key Management

Private keys—or a set of private keys—are often what manage a cross-chain bridge’s operations. The bridge operator or operators who individually hold a unique private key are tasked with coming to consensus and confirming the message or value being sent cross-chain by a user and delivering it accurately across chains. These messages are approved based on a digital signature, or a quorum of digital signatures, which are derived from the underlying private keys. 

Thus, private key compromises are one of the most common vulnerabilities for a cross-chain bridge, the culprit behind some of Web3’s most notorious cross-chain bridge hacks, often due to poor private key management or operational security practices. 

A general rule of thumb is that the more servers, infrastructure providers, locations, and operators, the more a cross-chain bridge and the private keys securing it are protected against single points of failure and centralization risks. 

Centralized networks are not only vulnerable to exploits, but enable centralized actors to unilaterally control all funds.

Decentralization helps mitigate centralization risks, which protects against the possibility of both internal and external attacks by requiring any malicious actor (even a bridge operator) to compromise the private key of multiple independent entities. It is a powerful form of security. However, it is only one consideration among many for secure private key management. Equally important are the security measures that bridge operators independently take to secure their private keys.

Best Practices

Decentralization is important for providing security against single points of failure, but private key security isn’t monolithic—the most secure cross-chain protocols combine the security that decentralization provides with time-tested methods of securing individual private keys. These include hardware security modules (HSMs), encryption (in transit, at rest), phishing education, access controls, key management services, and more.

Notable Real-World Cross-Chain Bridge Exploits Due to Compromised Private Keys

2. Unaudited Smart Contracts

Because the primary function of cross-chain bridges is to move value from one blockchain to another, it’s inevitable that all cross-chain protocols must deal with smart contracts.

In the vast majority of cross-chain use cases, smart contracts on multiple chains are leveraged to power the minting, burning, locking, or unlocking of tokens as they move across chains. These smart contracts are connected through cross-chain bridges, often in collaboration with token issuers.

Smart contracts are both an additional line of defense against exploits and a technical risk when constructed incorrectly. On one hand, smart contracts provide a valuable avenue for cross-chain bridges to enforce various common sense security checks, such as ensuring that a user cannot withdraw more than they have deposited and rate limiting. On the other hand, poorly written and unaudited smart contract code can have the exact opposite effect: Malicious hackers have exploited flaws in smart contract code to hack enormous amounts from cross-chain bridges.

It’s impossible for any project—no matter how security-sensitive it is—to guarantee that there are no technical bugs in its smart contracts’ code. However, one of the most battle-tested methods of ensuring solid, exploit-resistant code is to work with external, experienced auditors to battle-test a codebase before it is deployed in production. This is not a one-and-done initiative—even the most well-constructed codebases immediately become untested if code is changed after an audit or if unaudited contracts are introduced to an audited codebase.

Best Practices

Smart contract risk is very real when using a cross-chain protocol. The most secure cross-chain bridges continuously put their codebase to the test multiple times across both private audits and competitive audits, as well as a variety of internal security testing such as fuzz testing, static analysis, formal verification, symbolic execution, and more.

Checking to see how many times the codebase has been audited, and by whom, serves as a reliable signal that the cross-chain bridge being used is protected against technical exploits. Additionally, layered security, such as enabling emergency pauses and updates, as well as implementing rate limits, can mitigate the impact of any smart contract bug.

Real-World Cross-Chain Bridge Exploits Due to Smart Contract Risk

3. Unsafe Upgradability Processes

Upgradability refers to the ability to update a smart contract’s code, or change certain parameter configurations within the contract’s code. 

Developers often use upgradable contracts to update their smart contracts in order to add new features, address contract logic errors, and modify key risk parameters. In the context of cross-chain bridges, this allows for the ability to add support for new tokens and blockchains, implement new methods of validating cross-chain messages based on new technologies, adjust key risk parameters like rate limits and node composition, as well as swiftly address any unforeseen logic errors in the underlying smart contracts. 

Upgradable contracts require developers to build proxy contracts that sit in between the end-user and frontend implementation and the underlying smart contract logic contract.

Upgradability is important in a security context because if the upgrade process is not secure, it can introduce a potential attack vector. Secure upgradability with cross-chain bridges means taking a defense-in-depth approach, which includes robust private key management with keys held by multiple independent entities, timelock delays to allow users to inspect on-chain changes before they take effect, as well as robust approval processes such as the ability for cross-chain bridge operators to veto changes proposed in the timelock. To account for situations where an upgrade needs to be applied swiftly, explicit approval can be provided by the bridge operators after reviewing the changes. 

Best Practices

Upgradability is key to staying adaptable and accounting for unknown unknowns, but the upgradability process can be another vulnerability for cross-chain protocols if implemented incorrectly. Timelock contracts and node-veto mechanisms are important tools for hardening the upgradability process, but secure cross-chain bridges must also balance the need to provide an alternative path during time-sensitive circumstances, all while maintaining the highest standards of security. 

4. Single Network Dependency

Some cross-chain bridges rely on a single network of validators for all bridging operations. While this may work for bridges purpose-built to facilitate transactions between two specific blockchains, it is not a secure or scalable solution for general-purpose bridges that aim to seamlessly connect the disparate multi-chain world we live in today.

The most important reason to avoid bridges with this architecture is the disproportionate impact a bridge hack or exploit would have on users. Because all of the cross-chain transactions and the value associated with them are facilitated by a single monolithic network, any successful breach would result in a wide and comprehensive exploit of the bridge across all blockchains—with little to no separated risk.

Leveraging multiple independent and decentralized networks segregates the risk of a single exploit causing loss of funds across all blockchains and users.

A more secure (and scalable) design is an independent, multi-network design, which means:

Chainlink CCIP leverages multiple networks for a single cross-chain lane, making it the only cross-chain protocol to reach the fifth and highest level of cross-chain security.

Best Practices

Implementing multiple independent and decentralized networks for each cross-chain lane drastically reduces the attack surface and incentive for a malicious actor. Best-in-class implementations of this approach also include leveraging different coding languages for client diversity, separating responsibilities between networks with non-overlapping validator sets, and adding active risk management capabilities.

5. Unproven Validator Sets

The heart of any cross-chain bridge is its operators—the people and organizations responsible for maintaining the infrastructure that runs the cross-chain bridge’s operations.

Users, institutions, and dApp developers should be wary of unproven validator sets that lack the requisite experience and knowledge to securely and reliably operate a cross-chain bridge. A maximum-security cross-chain bridge requires world-class validator sets that all have extensive experience in operational security (OPSEC) to ensure proper private key management and reliable cross-chain transaction processing and execution.  

Chainlink nodes and the Chainlink oracle network are operated by world-class node operators.

The second point is largely overlooked by today’s users, devs, and institutions. A key risk for any cross-chain bridge user in regard to the underlying validator sets is that the validator set will not reliably execute transactions. For example, a user could lock up funds on one chain expecting a corresponding mint on another blockchain, but if the validator set is offline and does not approve the mint, it effectively freezes the user’s funds.

Best Practices

Cross-chain bridges should use only high-quality validators with a proven history of OPSEC experience, excellence, and rigor. Because OPSEC skills are not necessarily Web3-exclusive, this can include a variety of validators across both Web2 and Web3, but it’s always critical to verify the past performance of any cross-chain bridge validator. Additionally, adding economic security by requiring validators to put up collateral (stake) that is slashed in cases of misbehavior or unreliable operation can add additional incentives for validators to act honestly and reliably. 

6. No Active Transaction Monitoring

The goal of active transaction monitoring is to detect and react to anomalous behavior of a cross-chain bridge in real-time. When implemented properly, active transaction monitoring acts as a robust tool for detecting suspicious activity and immediately taking the necessary preventative measures to avoid a hack or exploit. 

A key example and use case for active transaction monitoring is for emergency pauses of the cross-chain system before executing suspicious transactions, or after a malicious transaction has bypassed the system, such as a successful request to withdraw a cross-chain bridge’s entire asset pool without the required collateral. 

Real-World Cross-Chain Bridge Exploits Due to No Active Transaction Monitoring

Best Practices

Active transaction monitoring should generally be performed by a separate entity or network from the cross-chain bridge’s primary validator set. This helps separate responsibilities and creates a checks-and-balances situation that reduces the possibility that a malicious operator, or operator set, can manipulate the real-time responses active transaction monitoring may trigger.

7. Lack of Rate Limits

Rate limits are not a new idea. In traditional software, rate limits are a security measure used by websites to prevent denial-of-service (DOS) attacks and by data providers to stop an overwhelming number of API requests from shutting down their servers. 

The concept is quite simple: Limit the number of requests that can be made by both time and volume. What kind of requests? In the cross-chain world, rate limits put a cap on the amount of value that can be transferred between chains within a given time span. 

This simple security measure is a powerful last line of defense for a cross-chain bridge. Even in the event of a successful hack or exploit that evades every other security measure, rate limits put a limit on how much value can actually be extracted from the cross-chain bridge. 

Rate limits are like a small hole in a bucket of water—only a predefined amount of water can leave the bucket at a time.

Real-World Cross-Chain Bridge Exploits Due to Lack of Rack Limits

Best Practices

Rate limits for assets should be determined on a per-lane basis for maximum security and modularity. Additionally, each lane should have an aggregate rate limit to limit the overall value that can be transferred on that lane across all assets. Implementing well-defined throughput rates (i.e., X tokens every 10 minutes max) can help prevent malicious actors from draining all assets within a bridge in a single transaction. “Refill rates” can also be applied to various cross-chain assets and lanes to avoid situations where malicious actors wait for a rate limit to reset to steal the maximum amount possible. 

Chainlink CCIP Provides Unmatched Cross-Chain Security

One key takeaway should be that cross-chain security is not as straightforward as implementing a single security measure. In reality, a robust cross-chain security design requires a defense-in-depth implementation that layers different security measures together to provide broad-spectrum protection against a hack or exploit.

The most secure cross-chain bridges employ defense-in-depth solutions that layer multiple security measures together.

That’s exactly how Chainlink CCIP—the industry-standard cross-chain solution—has been architected.