Cairo Smart Contract Security: How to Audit Starknet Without Missing the Real Risks

Cairo Smart Contract Security: How to Audit Starknet Without Missing the Real Risks

Most EVM auditors make the same mistake when they first look at Starknet.

They assume the hard part is learning new syntax.

Usually it is not.

The harder part is noticing that Starknet moves the risk. Some familiar instincts still help, but the audit surface shifts toward account abstraction, l1_handler validation, felt252 misuse, class-hash indirection, and cross-layer failure handling. A Cairo audit is not "the same audit on another chain." It is a different review with different trust boundaries.

This guide is for two readers:

• teams building on Starknet that want to know what a serious review should cover,

• Solidity auditors and researchers who want a practical mental model before they touch mainnet code.

Who This Is For

If you already know Solidity security, this article should help you reorient quickly.

If you are brand new to smart contract auditing, read it more slowly. Starknet introduces ideas that are manageable, but they are easier to understand once you already have a feel for authorization bugs, upgradeability risk, and state-machine reasoning.

Where Starknet Moves The Risk

At first glance, Starknet looks familiar. You still have contracts, state, access control, arithmetic, upgrades, and external interactions.

Then the foundation shifts.

That does not mean classic EVM bugs disappear. It means you should stop assuming they are still the center of the review.

If you want structured reps instead of only reading docs, the Cairo hacking course is a practical next step because it focuses on both Cairo fundamentals and the attack patterns auditors actually need to reason about.

The Cairo Risk Areas That Matter Most

1. Account Abstraction Expands The Authorization Surface

On Starknet, accounts are contracts. That is powerful, but it also means authentication logic is no longer background infrastructure.

The Starknet account model revolves around __validate__, __execute__, and related validation hooks. In practice, auditors care about a narrow set of failure modes over and over again:

• caller checks inside account execution,

• deprecated transaction-version handling,

• signature verification paths,

• replay resistance and nonce handling,

• custom module boundaries such as session keys or plugin-style account logic.

If your protocol depends on custom account behavior, your audit scope is broader than the application contract itself.

2. l1_handler Bugs Turn Bridge Boundaries Into Auth Bugs

L1 to L2 messaging is one of the clearest places where EVM muscle memory starts failing.

• Ethereum -> Starknet messages are delivered into l1_handler logic.

• Starknet -> Ethereum messages are consumed later on L1.

One particularly dangerous pattern is simple: the handler trusts from_address without checking that it matches the expected L1 sender.

L1 contract
  -> sendMessageToL2(...)
    -> sequencer creates L1 handler transaction
      -> #[l1_handler] executes on Starknet
        -> state changes happen

If the handler trusts the wrong L1 sender,
the bridge boundary stops being a trust boundary.

There is another subtle edge here. In L1 handler execution, helpers such as get_caller_address() return 0x0. If a developer imports EVM-style caller assumptions into that context, they can validate the wrong thing or skip validation entirely.

If your system crosses layers, audit the recovery path too. Message cancellation, retries, and partial-failure behavior are part of the security story, not just operational cleanup.

3. felt252 Is Not Just "Another Integer"

Many Cairo accounting bugs start with the wrong type choice rather than a visibly broken formula.

felt252 lives in field arithmetic, not in the bounded-integer model most Solidity developers expect. Cairo's integer types are safer for business logic that depends on natural bounds, explicit overflow behavior, or predictable conversion rules.

That is why good Cairo reviews keep asking questions like:

• Should this value be u128 or u256 instead of felt252?

• Can subtraction or conversion here produce a state transition the business logic did not intend?

• Are we comparing field elements where bounded arithmetic was actually required?

// Simplified example.
// The bug is not syntax. The bug is choosing the wrong numeric model.

let previous_balance: felt252 = self.balances.read(user);
let next_balance: felt252 = previous_balance - withdrawal_amount;

self.balances.write(user, next_balance);

If the design expected bounded integer behavior, that snippet deserves a second look.

4. No delegatecall Does Not Mean No Indirection Risk

Starknet removes one familiar EVM hazard and replaces it with a different trust problem.

If user-controlled or weakly validated class references can influence execution, you still have a critical indirection issue. The implementation details differ from delegatecall, but the question is similar: who decides what code the system trusts next?

For upgradeable systems, review at least these paths:

• who can change class hashes or implementation references,

• whether class updates are validated through governance or allowlists,

• storage compatibility assumptions across upgrades,

• initialization and re-initialization behavior,

• emergency pause and rollback paths.

Tools such as Caracal are useful here, but only as a first pass. Architecture-level trust mistakes still require a human to model the system.

5. Reentrancy-Style And Read-Only State Bugs Still Exist

Starknet constrains some EVM-style reentrancy patterns, but it does not eliminate call-order bugs, stale-read problems, or state assumptions that become false after an external interaction.

That is why reviewers still care about:

• storage reads before external interactions,

• writes that happen too late,

• view-like paths that expose stale or misleading state,

• multi-contract flows where a security invariant depends on call order.

If you want a quick refresher on the exploit class itself, the site's guide to /attacks/reentrancy is still relevant. The mechanism changes shape, but the adversarial reasoning does not.

What A Real Starknet Audit Should Look Like

There is a big difference between "we ran a tool" and "we reviewed the system."

1. Map The Architecture First

Start with accounts, protocol contracts, admin roles, upgrade paths, bridges, and every cross-layer trust boundary. If the architectural map is wrong, the rest of the audit will be wrong too.

2. Model Cairo-Specific Failure Paths

Before line-by-line review, list the failure modes you expect to matter:

• broken account validation,

• weak l1_handler authorization,

• class-hash or library-call trust mistakes,

• felt252 misuse in business logic,

• stale-state and read-only hazards.

This keeps the audit anchored in the execution model instead of drifting back into a generic Solidity checklist.

3. Use Tooling For Breadth, Not Proof

Static analysis and tests are useful for surfacing patterns quickly. They are not the final argument that the system is safe.

tooling for breadth
  +
manual review for trust boundaries
  +
tests for exploitability
  +
architecture review for cross-layer failure modes

4. Review Recovery And Failure Handling

The happy path is not enough. Bridge cancellation, retry behavior, privilege boundaries, broken upgrades, and emergency procedures all belong in scope if the protocol depends on them in production.

Tooling That Helps, And What It Does Not

The current Cairo tooling stack is good enough to accelerate a review, but not good enough to replace one.

Caracal is useful for catching common patterns. It is not a substitute for manual reasoning about protocol economics, upgrade control, or cross-layer assumptions. The best audits still combine tooling with architecture review and exploit-oriented testing.

A Practical Pre-Mainnet Checklist For Starknet Teams

If you are shipping on Starknet, these are the questions worth answering before launch.

Account Layer

• Does __execute__ enforce the caller and transaction-version checks Starknet explicitly warns about?

• Is signature validation consistent across all account entry points?

• Are nonces, replay assumptions, and session-key permissions narrow and testable?

Protocol Layer

• Are privileged functions obvious, minimal, and correctly gated?

• Are class-hash and upgrade operations strongly controlled?

• Are felt252 values used only where field arithmetic is actually intended?

• Do read-only helpers and state-changing flows agree on the same invariants?

Messaging Layer

• Does every l1_handler verify the expected L1 sender?

• Has the team tested message failure, retry, and cancellation paths?

• Are cross-layer assumptions documented on both the L1 and L2 sides?

Operational Layer

• Is there an emergency plan for a stuck bridge path or broken upgrade?

• Are dependency versions pinned and release procedures explicit?

• Are security tests running before deploys rather than after incidents?

That is not the deluxe package. It is the baseline.

If You Are Moving From Solidity To Cairo

The fastest way to become useful in Cairo security is not to read every doc in order. It is to learn the handful of Starknet concepts that move trust and failure handling.

If you want useful practice, focus on these five areas first:

1. Starknet account validation.

2. L1-L2 messaging and handler authorization.

3. felt252 versus bounded integers.

4. Upgradeability and class-hash control.

5. Call-order bugs, stale reads, and exploit-oriented testing.

Reading And Next Steps

If you want the shortest route from Cairo-curious to actually useful, start here:

• Starknet accounts documentation

• Starknet L1-L2 messaging documentation

• The Cairo Book

• Caracal

• OpenZeppelin Contracts for Cairo

• Starknet Foundry

• The site's vulnerability library, including /attacks/access-control-attacks, /attacks/replay-attacks, and /attacks/reentrancy

If you want broader exploit context while you study, keep /tools/web3-hacks-dashboard open next to the docs.

If you want hands-on reps instead of another reading list, the Cairo hacking course is the most direct way to practice the attack surface this article described.

If you are a few weeks from mainnet and want outside eyes while changes are still cheap, start with the contact form. If you already need budgeting context for a formal review, the /tools/smart-contract-audit-cost-estimator is the fastest next step.

Final Take

Starknet security is not EVM security with different syntax.

It is a different trust model with a different distribution of risk.

Teams that understand that early make better design decisions. Auditors who understand it early find bugs other reviewers still walk past. The practical playbook is simple: learn the model, trace the trust boundaries, test the failure paths, and do not confuse novelty with safety.