Memory safety
Also known as: memory-safe languages, memory safe programming, memory-safe code
Memory safety is a property of software, or the programming language it's written in, that prevents bugs such as reading past the end of a buffer or using memory after it's been freed.
These mistakes, common in C and C++, cause a large share of serious security vulnerabilities. Languages such as Rust, Go, Java, C#, and Swift are designed to prevent them. While rewriting everything is unrealistic, writing new code in memory-safe languages has sharply cut vulnerability rates at companies like Google.
Memory safety, explained at three levels
At home
A computer's memory is like a long row of numbered mailboxes, each holding a piece of a program's data. A memory safety bug happens when a program reaches into the wrong mailbox, such as one past the end of its own, or one it has already given back. Attackers use those mistakes to slip in their own instructions. Memory-safe languages check every reach automatically, so the mistake can't happen.
At work
Memory safety means software can't accidentally read or write parts of memory it shouldn't. Programs written in older languages such as C and C++ can make these mistakes, and they cause most serious security flaws in browsers and operating systems. Languages such as Rust, Go, Java, and C# prevent them by design, so businesses choosing them for new software remove a major source of vulnerabilities.
At home
Programs keep data in memory in chunks of a set size. In older languages such as C and C++, nothing stops a program from writing past the end of a chunk or using one after it has been freed. Attackers exploit those mistakes to overwrite important data or redirect the program to their own instructions. Memory-safe languages check every access automatically, so the mistake causes an error instead of handing control to an attacker.
At work
The main bug classes are buffer overflows, out-of-bounds reads, use-after-free and double-free, plus type confusion. Memory-safe languages prevent them through bounds checking, garbage collection, as in Java, C# and Go, or compile-time ownership rules, as in Rust, which avoid the runtime cost of a garbage collector. For existing C and C++ code, sanitizers such as AddressSanitizer catch bugs in testing, and hardening such as memory tagging on newer Arm chips catches some in production.
At home
Microsoft and Google have both reported that around 70 percent of their serious security bugs were memory-safety problems. When companies write new code in safer languages, that class of bug largely disappears from the new parts. Google has said Android's memory-safety vulnerabilities fell sharply as more new code moved to Rust and Kotlin. In my view, it is one of the quiet reasons phones have become harder to hack, even though you never see the change.
At work
Rewriting everything is impractical, so strategies focus on new code and the riskiest components first: parsers, codecs and network-facing services handling untrusted input. Interfaces between safe and unsafe code need careful review, since Rust's unsafe blocks and C bindings reintroduce risk. CISA and partner agencies, including the Canadian Centre for Cyber Security, have urged vendors since 2023 to publish memory-safety roadmaps. Ask suppliers for theirs, and enable compiler and hardware mitigations for legacy code.
Real-world examples
At home
Sophie noticed that many phone security updates mentioned fixing 'memory corruption' bugs. Reading further, she learned these flaws are the main way spyware breaks into phones.
At work
Carlos leads engineering at a Montreal networking startup. He required all new code that handles internet traffic to be written in Rust, reducing the most dangerous class of bugs from the start.
How it compares
| feature | Memory-safe languages | Memory-unsafe languages |
|---|---|---|
| Examples | Rust, Go, Java, C#, Swift | C, C++ |
| Buffer overflows | Prevented by design | Possible |
| Performance | Often close to C | Very high |
| Existing code | Less legacy software | Huge legacy base |
Memory-safe languages remove a whole category of security bugs.
For analysts
When buying software or planning new systems, I'd ask vendors about their memory safety plans. It's a forward-looking question that separates serious security cultures from the rest.
History & origin
Buffer overflows were exploited by the Morris worm in 1988, and Aleph One's 1996 article explained them to a generation of attackers. Microsoft engineers reported in 2019 that about 70 percent of the security vulnerabilities they fixed each year were memory safety issues, and Google reported a similar share for Chrome in 2020. Mozilla sponsored the Rust language, which reached version 1.0 in 2015, and Rust was accepted into the Linux kernel in 2022. US agencies including the NSA and CISA, along with allies including Canada's Cyber Centre, urged a shift to memory-safe languages from 2022 onward, and the White House issued a report on it in February 2024. Google said memory safety bugs fell from about 76 percent of Android vulnerabilities in 2019 to 24 percent in 2024 as new code shifted to memory-safe languages. In my view, memory safety is one of the rare security problems with a clear, proven fix.