Secret Vault on Aptos

[M-1]: Lack of Resource Management Causes Transaction Failures

Description

A user should be able to query the contract to see if a secret exists without causing an error. However, the get_secret function directly attempts to borrow_global without first checking if a Vault resource actually exists. If no vault has been created, this operation will fail and cause the entire transaction or view call to abort.

Risk

Likelihood: Medium

• It is a common and expected behavior for a user or front-end application to check for a value before one has been set. This will always fail.

Impact: Low

• This flaw does not lead to data loss or theft, but it represents poor design and creates a brittle contract. It forces front-ends to build complex, off-chain logic to avoid calling a function that should be safe to call.

Proof of Concept

The issue is a direct result of the borrow_global function's defined behavior in Move.

1. The contract is deployed. No one has called set_secret yet, so no Vault resource exists at the @owner address.

2. A front-end or user calls the get_secret view function to check the current secret.

3. The function executes borrow_global<Vault>(@owner).

4. The Move VM requires that the resource must exist for borrow_global to succeed. Since it doesn't, the VM aborts the execution with an ERESOURCE_NOT_FOUND error.

Recommended Mitigation

The function should first check for the resource's existence and return an Option type, which is the standard way to handle optional values in Move. This makes the function robust and easier to integrate with.