Full Report
Every programming language has its pros and cons in terms of security. This article is from Aptos about writing secure smart contracts within the MOVE programming language. Access control is the first thing listed with several sub categories - probably the most important thing to look out for. MOVE, similar to Solana, accepts a signer object, for the calling user. Using this in the proper places is important. Similar to Solidity, different functions have different visibilities. entry is used for entrypoints into modules. friend should be used for functions to be accessible by specific modules, which I think are other things. view functions are for only reading data. public functions are accessible from through modules as well. private are only accessible by the module itself. The next category stems from types and data structures. First, they talk about generic type checks. When taking in a generic type, proper validation to ensure there are weird type confusions. phantom data types should be used to prevent this. The other data structure related item is resource management and unbounded execution. Being careful with unbounded data storage, unbounded array iteration and other things. Move abilities are a set of permissions that control the actions on data structures. These act as defense-in-depth measures to ensure specific operations do not happen. The four capabilities are copy, drop, store and key. Now, for something specific to Aptos. When creating an object the ConstructorRef should not be controllable by end users or passed around. If it is, then resources can be added to it or changed directly in storage. Individual objects should also be stored in separate objects. Otherwise, transferring of ownership of the account will result in the whole ownership of it to the new user. The final section is about business logic. Aptos is still vulnerable to oracle manipulation and frontrunning. Overall, a good overview of Aptos security for somebody who has never looked into it.
Analysis Summary
# Best Practices: Secure Smart Contract Development in Move (Aptos)
## Overview
These practices address the unique security architecture of the Move programming language and the Aptos blockchain. They focus on preventing unauthorized access, ensuring data integrity through Move's type system, and mitigating common smart contract vulnerabilities like unbounded execution and business logic manipulation.
## Key Recommendations
### Immediate Actions
1. **Validate All Signers:** Always use the `signer` object to verify the identity of the caller in functions that perform sensitive operations or modify state.
2. **Apply Strict Visibility:** Default to `private` or `entry` visibility. Only use `public` or `friend` when absolutely necessary for cross-module interaction.
3. **Secure the `ConstructorRef`:** Ensure that the `ConstructorRef` generated during object creation is never exposed to end-users or passed to untrusted functions, as it grants full administrative control over the object.
### Short-term Improvements (1-3 months)
1. **Implement Phantom Types:** Use `phantom` type parameters in generic structures to prevent type confusion attacks where an attacker might try to substitute one asset type for another.
2. **Audit Data Structures for "Abilities":** Explicitly define `copy`, `drop`, `store`, and `key` abilities for every struct to enforce the principle of least privilege at the data layer.
3. **Decouple Object Storage:** Store individual resources in separate objects rather than bundling them. This prevents accidental mass-transfer of assets when ownership of a parent account or object changes.
### Long-term Strategy (3+ months)
1. **Eliminate Unbounded Loops:** Refactor code to avoid iterating over arrays or data structures that can grow indefinitely, which prevents "Out of Gas" DoS attacks.
2. **Oracle and MEV Hardening:** Develop robust price-averaging mechanisms (like TWAP) to mitigate oracle manipulation and implement slippage protection to defend against frontrunning.
## Implementation Guidance
### For Small Organizations
- **Manual Code Reviews:** Focus heavily on checking visibility modifiers (`entry`, `friend`, `public`) and ensuring `signer` checks are present on all state-changing functions.
- **Strict Resource Control:** Use Move’s abilities to ensure assets cannot be accidentally duplicated or dropped.
### Medium Organizations
- **Automated Testing:** Implement unit tests specifically targeting generic type edge cases and type confusion.
- **Resource Management:** Establish internal standards for avoiding unbounded data storage to ensure predictable execution costs.
### For Large Enterprises
- **Formal Verification:** Leverage Move's Prover to formally verify that business logic and access control rules cannot be bypassed.
- **Advanced MEV Protection:** Implement sophisticated defense-in-depth measures against transaction ordering manipulation and flash loan-funded oracle attacks.
## Configuration Examples
### Function Visibility Hierarchy
| Visibility | Access Level | Recommended Use |
| :--- | :--- | :--- |
| `private` | Only current module | Internal logic and helpers. |
| `entry` | External CLI/SDK calls | Primary entry points for users. |
| `friend` | Specific trusted modules | Shared logic between related modules. |
| `public` | Any module | Standardized interfaces (use sparingly). |
| `view` | Read-only | Data retrieval for UIs and other contracts. |
### Resource Abilities
- `copy`: Use only for non-scarce data.
- `drop`: Use for temporary values; avoid for tokens/assets.
- `store`: Required if the struct needs to be stored inside another struct.
- `key`: Required for a struct to be used as a top-level resource in storage.
## Compliance Alignment
- **SWC Registry (Smart Contract Weakness Classification):** Directly addresses Authorization (SWC-105) and Unprotected Functions (SWC-100).
- **NIST Cybersecurity Framework:** Aligns with "Protect" (PR.AC) by enforcing granular access control through Move's native capabilities.
## Common Pitfalls to Avoid
- **ConstructorRef Leakage:** Passing a `ConstructorRef` to a public function, allowing attackers to add unauthorized resources to your objects.
- **Unbounded Growth:** Allowing user-generated data to increase the size of a global resource without limits, eventually making the resource too expensive to load.
- **Generic Type Confusion:** Failing to use `phantom` data types, which can allow an attacker to trick a contract into treating a "FakeToken" as a "RealToken."
## Resources
- **Aptos Move Documentation:** hxxps://aptos[.]dev/move/book/
- **Move Prover Guide:** hxxps://aptos[.]dev/guides/move-guides/prover/
- **Aptos Framework GitHub:** hxxps://github[.]com/aptos-labs/aptos-core/tree/main/aptos-move/framework