The first rule in access control is the `principle of least privilege` which states that users should have the minimum necessary privileges required to do their job. 
This can often be difficult to implement in smart contracts, as it would require managing many different accounts, therefore it is common to see the privileged functions of a smart contract being protected by at least an `owner` role, which ideally is secured by a multi-signature wallet.

With Cairo, we have two main libraries which can be used to implement access control (both provided to us by OpenZeppelin):

* [Ownable](https://github.com/OpenZeppelin/cairo-contracts/blob/main/openzeppelin/access/ownable.cairo)
* [AccessControl](https://github.com/OpenZeppelin/cairo-contracts/blob/main/src/openzeppelin/access/accesscontrol/library.cairo)

It is important to ensure that the roles implemented fit the purpose of the protocol, and have the least possible amount of privileges. Furthermore, use of multi-signature wallets where appropriate is highly encouraged.

For instance, if we were to implement a custom ERC20 contract, we could implement the following roles:

* `Owner` or `Admin` - Owns the contract and can transfer ownership/assign roles to others as well as perform other management activity
* `Minter` - Can mint new tokens
* `Pauser` - Can pause the contract
* `Upgrader` - Can upgrade the contract (in case of an upgradeable contract)

As mentioned above, we have two options for this, either use `Ownable` or `AccessControl`. For impementing more roles, it makes more sense to use `AccessControl`, as otherwise we would have to make amendment to the `Ownable` library, which is not recommended.

With `AccessControl`, we can set arbitrary roles, and have them verified in a similar fashion. In this case, we will set the admin role in the constructor of our contract, just after initializing the library. Now that we have an admin role, we can use it to set all other roles. Let's try and implement a `minter` role:

```javascript 
@external
func grantRole{
        syscall_ptr : felt*,
        pedersen_ptr : HashBuiltin*,
        range_check_ptr
    }(role: felt, user: felt) {
    AccessControl.grant_role(role, user);
    return ();
}
```

And then protect our `mint` function to only allow the `minter` to call it, using a modifier which looks like the one below:

```javascript 
func assert_only_role{
        syscall_ptr : felt*,
        pedersen_ptr : HashBuiltin*,
        range_check_ptr
    }(role: felt) {
    alloc_locals
    let (caller) = get_caller_address();
    let (authorized) = has_role(role, caller);
    with_attr error_message("AccessControl: caller is missing role {role}") {
        assert authorized = TRUE;
    }
    return ();
}
```

And this is our code with the new added check:

```javascript 
@external
func mint{
        syscall_ptr: felt*,
        pedersen_ptr: HashBuiltin*,
        range_check_ptr
    }(to: felt, amount: Uint256) {
    let (caller) = get_caller_address();
    AccessControl.assert_only_role(120299592115570, caller);
    ERC20._mint(to, amount);
    return ();
}
```

And this should fail if the caller does not have the minter role.

How to use Access Control in Cairo securely? What library can I use for implementing it?

How to use Access Control in Cairo language securely?

Proxies allow to extend the functionality of a smart contract by making it essentialy modifiable. One of the key properties of smart contracts is their immutability, however there have been many examples where this has been a problem in the past. 

For instance, a protocol identifying a serious bug while deployed on mainnet, and not being able to fix it. Or a hacker exploting a bug and no way to remediate the issue (btw, [pausing](https://github.com/OpenZeppelin/cairo-contracts/blob/main/src/openzeppelin/security/pausable/library.cairo) functionality would be really useful here too). Sure, one could re-deploy the contract, but what about the contract storage? 

Due to this, knowing how to safely implement the proxy pattern can be a great tool in a developer's arsenal. 

Yet again, OpenZeppelin made everyone's life easier and implemented a standard [Proxy pattern](https://docs.openzeppelin.com/contracts-cairo/0.4.0b/proxies) which anyone can use to make their contracts upgreadable. 

Here is the default Proxy preset provided by [OZ](https://github.com/OpenZeppelin/cairo-contracts/blob/main/src/openzeppelin/upgrades/presets/Proxy.cairo). This is very simple, has the `__default__` function (which is like our fallback in Solidity), a `L1 handler`, and a constructor. Before deploying this contract, developers should declare the contract class of their implementation contract. After, they can deploy the Proxy contract and pass the implementation_hash as parameter to the constructor.

The actual Proxy library contract contains a couple of `storage_var` as seen below:

```javascript 
@storage_var
func Proxy_implementation_hash() -> (class_hash: felt){
}

@storage_var
func Proxy_admin() -> (proxy_admin: felt){
}

@storage_var
func Proxy_initialized() -> (initialized: felt){
}
```

Always remember to not deploy your implementation contract (the one that contains the actual logic of your protocol). Instead this should be `declared` as a `contract_class` with:

`starknet declare --contract contract_compiled.json`

One other important piece of advice to keep in mind is to use the [initializer](https://github.com/OpenZeppelin/cairo-contracts/blob/main/src/openzeppelin/security/initializable/library.cairo) "modifier" for the initialization function of an implementation contract. This will prevent your contract from being initialized twice (which could be a very big problem).

What is the proxy pattern and how it can help make my smart contracts upgradable in Cairo Language? Is there any standard lib for that?

What is the proxy pattern and how it can help make my smart contracts upgradable in Cairo Language?

While not all (if any) libraries available for StarkNet's contract have been audited, it is important to make use of battle tested and trustworthy libraries. StarkNet has a pretty tight community, so when in doubt, ask on Discord, on one of the many telegram groups or [Newton](https://www.newton.wtf/), and other devs will be able to guide you on choosing the best libraries. 

As usual, the most reputable and useful collection of libraries is OpenZeppelin's [cairo-contract](https://github.com/OpenZeppelin/cairo-contracts). For any other need, have a look at [Cairo Goldmine](https://github.com/beautyisourbusiness/cairo-goldmine).

As the ecosystem matures, we will surely see more and more libraries being audited and this will allow a more standardised way of writing smart contracts. In the meantime, when in doubt, always ask your fellow developers/security engineers.

What libraries are secure to use in the Cairo language? How to know which library is audited? 

What libraries are secure to use in Cairo?

Reentrancy is a very common attack in smart contracts, due to contracts often being required to call other contracts. As we cannot control what another contract does, it might be possible that the called contract initiates a callback to the original contract. This can be very dangerous if the original contract does not follow the checks-effects-interaction pattern, which states that we should not make changes to state variables after interacting with an external entity. 

For instance, let's take a (very generalized) contract which stores users balances and allows to make transfers using arbitrary tokens. In this case, the pattern should be the following:


* Check that the user has enough funds to transfer
* Decrease the balance of the sender and increase the balance of the receiver
* Perform the transfer using the external token contract


Should step 2 and 3 be inverted, and the arbitrary contract called would perform a callback to our original contract, the balance of the user would not have been updated and another transfer could be made on its behalf. 

On top of following the checks-effects-interaction pattern, we can use Reentrancy guards to protect our contracts. In Cairo, we have OpenZeppelin's [implementation](https://github.com/OpenZeppelin/cairo-contracts/blob/main/src/openzeppelin/security/reentrancyguard/library.cairo).


This is as simple as calling `ReentrancyGuard._start()` at the beginning of a function, and `ReentrancyGuard._end()` at the end. This will prevent any reentrant call in the code, as if the funciton is reentered, it will error out due the storage variable `ReentrancyGuard_entered` being set to true. An example below:

```javascript 
@external
func callback{syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr}() {
    ReentrancyGuard._start();
    _count();
    ReentrancyGuard._end();
    return ();
}
```


Everyone knows that secure code is essential. Can someone explain what is reentrancy?
I am curious about the reentrancy attack in StarkNet – is it a problem in Cairo Language and how to protect my smart contract from this attack?

How to protect my contract from reentrancy in Cairo Language / StarkNet?

Audits are an important step in the launch of any protocol. It is always recommended to get at least one audit from a reputable firm, as they will (hopefully) find bugs in your code. In order to maximise your chances of shipping a secure product, you should aim to have two companies audit your protocol (if funding allows of course). This allows some room for errors from an auditing firm, as auditors are human and can make mistakes and miss some vulnerabilities. 

Also, running a bug bounty program on a platform such as [Immunefi](https://immunefi.com/) is a good way to incentivize white hat hackers to look at your code and help you. Finally, [Code4rena](https://code4rena.com/) is a great way to have some of the best minds in blockchain security try to break your code.

The following steps should be completed before submitting a project for an audit, as this will save time to the auditors (and reduce costs) as well as increase the chances of finding any bugs before the code is audited.

- Make sure that the code is well commented
- Make sure that appropriate documentation is produced (more often than not, writing up documentation will lead you to finding some bugs yourself)
- Implement thorough test cases (Auditors really appreciate that)
- Research audit companies and choose one which fits your budget and which you would feel safe with
- Identify areas of concern which you believe might have bugs (This gives the auditor a good starting point)
- Gather documentation and updated deployment scripts to allow auditors to hit the ground running

We are building a security team under the name Spectra. If you are interested in getting your Cairo smart contracts (or Solidity and other technologies) audited, feel free to reach directly to [@ctrlc03](https://twitter.com/ctrlc03) or to [@spectra_sec](https://twitter.com/spectra_sec).

How can I prepare my Cairo lang project for an audit?

Popular tags

Profile

ctrlc03

Wallet address: 0xDF2ad1Aebb9A62A1b8CbBf8D7666A7A8b894178d

Recent questions

Recent answers