Exploits on back- and front-end

[jvel07]

@liarco your repository is one of the best out there. Congrats and keep it up, I am a big fan of all your socials.
I am aware that we should use this repo under our own responsibility, however, given the increased hacks and exploits in the space, I must ask a few questions about it.

Recently, a hyped collection got exploited --> B_F_Party, see details on Twitter here. Seems like the exploit was on their front-end, allowing an individual to mint ~200 at once. This is worried the entire community, naturally.

My question is more regarding what extent the components (smart contract, front and back ends, and all that apply) of this repository are/were security audited?

Again, I find this repo very useful, this is just a concern that I think could affect many people in the space and would be good to be aware of beforehand. Thanks again!

[liarco]

Hi @jvel07, thank you for your feedback! I converted this to a discussion since issues are for bug reports only.

First of all, I totally understand your concerns and I agree it's really hard to trust projects in this space. This repository never received audits from third-party. It has been used by many collections, we use it ourself, we received personal appreciation from people working for popular auditing firms, but none of this can replace an official audit.

That said, I would like to touch some points about this topic...

Considerations about exploit you mentioned

For anyone else reading this, the exploit mentioned here is not related to this repo. They were using custom code for both the contract and the dApp.
A part from this, the tweet looks really strange to me:

Due to the oversight on my part, there was a front-end exploit on our website today which allowed a particular individual to mint multiple NFTs from our contract.

A dApp (decentralized application) cannot be exploited. Due to its nature, it's just a UI that gives people direct access to the back end, which is the contract itself. If the front end can be exploited, then it means it's not a dApp... it must have a back end or maybe it has special privileges on the contract. In my opinion, this is very dangerous and should be avoided since, in most situations, we don't need it thanks to the way blockchain technologies work.

Our "minting dApp" is a dApp. You can't exploit it, because it's just a plain interface to the contract on the blockchain. There is no custom back end, it's just a plain static React app that makes it easier for people to interact with the blockchain.

Every single piece of data made public through the dApp is not sensitive:

• contract data (address, ABI, bytecode, etc.): this stuff is public
• collection configuration (prices, amounts, etc): this stuff is public
• whitelist addresses and Merkle Tree root hash: this stuff is public

If you are concerned about dApp security, then I did my best to make sure this dApp can be broken (so it doesn't work if you don't use it properly), but it cannot be exploited, because it does nothing that you can't do by simply sending transactions manually to the blockchain.

Considerations about the smart contract

I get tons of feature requests each day by users and devs, and I'm really sorry but I usually have to reject most of them. The reason why is: the only way to keep this project strong and safe is to keep it simple.

This project stands on the shoulders of giants like the team behind ERC721A. We used their contract as a base for our implementation and we kept the customizations on our side to the minimum.

As always, our effort alone cannot replace proper audits, everyone can do mistakes, but we do our best and we are really concerned about security.

Considerations about the project architecture

I also want to clarify how this project works, because you specified smart contract, front and back ends, and all that apply and I wanna make sure there is no confusion about this.

This project has 2 components:

• Solidity smart contract: this is the back end. This is the only thing that contains the logic about how things work. The deployer wallet must be kept safe since it's used in order to perform admin tasks, but those tasks (as well as anything else) are managed by the contract, not by any off-chain code
• minting dApp: this is a static and stateless GUI. This is just a graphical representation of the actions you can perform on the contract. It allows unexperienced users to send transactions in a easier (and engaging) way

There is nothing more than this.

Further considerations

• the Merkle Tree solution for the whitelist uses just public data in order to work, so the list of addresses, the root hash, even the proof for a specific address can all be shared publicly. Nobody will be able to take advantage of that because of how Merkle Tree verification is designed
• Your project folder may contain sensitive data that must be kept secret and you should never push them to a remote repository (e.g. API keys for services, private keys of your wallet, etc.). I did my best to prevent this from happening by mistake, but people must pay huge attention to this

Hi hope this is helpful, feel free to ask if you have any questions.

[jvel07]

Thanks for your extensive and detailed reply. You are one of a kind, literally! Please, never change, I know it must be overwhelming sometimes but the attention you give to people is unprecedented and valuable!
Not to mention your technical skills. Thanks again for your answer.

One last question would be just to clarify whether this repo (nft-erc721-collection) is already based on the contract ERC721A? I only ask this because the name of the repo misses the 'A'.

[liarco]

Thank you @jvel07 for your kind words. I really do appreciate it.

About the ERC721A question, the default contract you get form this repo is based on their implementation:

nft-erc721-collection/smart-contract/contracts/YourNftToken.sol

Line 10 in e2ae0cc

contract YourNftToken is ERC721AQueryable, Ownable, ReentrancyGuard {

ERC721AQueryable is one of their official extensions which implements some useful functions over the basic version.