unsafe in Rust does not switch off the borrow checker or other safety checks. It only unlocks five operations the compiler cannot verify for memory safety. Your job is to keep those blocks small and hide them behind a safe API.
The five unsafe superpowers
The Rust Book lists exactly these:
- Dereference a raw pointer.
- Call an unsafe function or method.
- Access or modify a mutable static variable.
- Implement an unsafe trait.
- Access fields of unions.
The book states that unsafe "doesn't turn off the borrow checker or disable any of Rust's other safety checks." A reference used inside an unsafe block is still checked. The keyword just grants those five abilities without compiler verification.
Why this helps reviewers
Because those operations must sit inside unsafe blocks, any memory safety bug in your own code must be traceable to one of them, or to a bug in a library that uses them. That turns an audit from "read everything" into "read the unsafe blocks and the invariants around them."
The book's advice is direct: keep unsafe blocks small, because you will be thankful when you investigate memory bugs.
Wrap it in a safe abstraction
The book recommends enclosing unsafe code inside a safe abstraction with a safe API, so that use of unsafe does not leak into every caller. Its example is split_at_mut, which checks that the split point is within the slice length and then uses a tiny unsafe block to build two slices.
Apply the same pattern in your own code:
- Check the preconditions in safe code before the unsafe block.
- Document the invariant the block relies on in a comment, next to the block.
- Expose only a safe function.
pub fn first_byte(buf: &[u8]) -> Option<u8> {
if buf.is_empty() {
return None;
}
// SAFETY: buf is non-empty, so index 0 is in bounds.
Some(unsafe { *buf.get_unchecked(0) })
}
A review checklist for unsafe
- Is there a
SAFETYcomment that states why the operation is sound? - Are preconditions checked in safe code before the block?
- Can the block be smaller?
- Is there a safe alternative in the standard library?
- For FFI, who owns the memory, and who frees it?
See also auditing unsafe Rust FFI boundaries for the boundary cases.
What unsafe code in dependencies means for you
Crates you depend on may contain unsafe blocks. That is normal for low level libraries, but it makes dependency hygiene matter. Keep crates current and check advisories.
Safeguard's SBOM and dependency scanning and reachability analysis can show which advisories in your crate tree your code actually reaches. A free scan is at gold.safeguard.sh/scan.
Quick check
Does unsafe disable the borrow checker?
No. The Rust Book says it does not turn off the borrow checker or any other safety checks, and only allows five specific operations.
Should I avoid unsafe completely?
Use it only where needed, keep blocks small, and prefer safe abstractions. Some tasks, such as FFI, require it.
Sources
Last reviewed: 19 October 2026.
