Memory-Safe Languages
What is Memory-Safe Languages?
Memory-Safe LanguagesMemory-safe languages such as Rust, Go, Swift, Java, and C# prevent the spatial and temporal memory errors that drive most exploitable vulnerabilities in C and C++.
Memory-safe languages enforce bounds, ownership or garbage-collected lifetimes, and type integrity at compile or run time. Rust uses an ownership and borrow checker for safety without a garbage collector; Go and Swift rely on managed allocation with bounds-checked slices; Java and C# use a managed runtime. The U.S. Office of the National Cyber Director (ONCD) 2024 report Back to the Building Blocks recommends adopting memory-safe languages for new code and critical components to eliminate the 60-70 percent of high-severity vulnerabilities attributable to memory bugs. Adoption strategies include rewriting hotspots (Android, Windows kernel, curl), strangler patterns, and FFI boundaries for legacy interop.
● Examples
- 01
Android shipping the Bluetooth stack components in Rust to reduce UAF risk.
- 02
AWS rewriting parts of Firecracker and s2n-tls in Rust for memory safety.
● Frequently asked questions
What is Memory-Safe Languages?
Memory-safe languages such as Rust, Go, Swift, Java, and C# prevent the spatial and temporal memory errors that drive most exploitable vulnerabilities in C and C++. It belongs to the Application Security category of cybersecurity.
What does Memory-Safe Languages mean?
Memory-safe languages such as Rust, Go, Swift, Java, and C# prevent the spatial and temporal memory errors that drive most exploitable vulnerabilities in C and C++.
How does Memory-Safe Languages work?
Memory-safe languages enforce bounds, ownership or garbage-collected lifetimes, and type integrity at compile or run time. Rust uses an ownership and borrow checker for safety without a garbage collector; Go and Swift rely on managed allocation with bounds-checked slices; Java and C# use a managed runtime. The U.S. Office of the National Cyber Director (ONCD) 2024 report Back to the Building Blocks recommends adopting memory-safe languages for new code and critical components to eliminate the 60-70 percent of high-severity vulnerabilities attributable to memory bugs. Adoption strategies include rewriting hotspots (Android, Windows kernel, curl), strangler patterns, and FFI boundaries for legacy interop.
How do you defend against Memory-Safe Languages?
Defences for Memory-Safe Languages typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Memory-Safe Languages?
Common alternative names include: MSL, Memory safe languages.
● Related terms
- appsec№ 670
Memory Safety
Memory safety is the property that a program never reads, writes, or executes memory it has not legitimately allocated, preventing entire classes of vulnerabilities.
- appsec№ 953
Rust Security Properties
Rust enforces memory and thread safety at compile time through ownership, borrowing, and lifetimes, eliminating common UB classes such as use-after-free and data races without a garbage collector.
- appsec№ 217
Control-Flow Integrity
Control-Flow Integrity (CFI) constrains a program's indirect calls and returns to a precomputed set of legitimate targets, blocking ROP and JOP exploits that hijack control flow.
- appsec№ 064
ASLR
Address Space Layout Randomization randomizes the memory locations of code, stacks, heaps, and libraries so attackers cannot reliably predict target addresses for exploits.
- appsec№ 925
Return-Oriented Programming
Return-Oriented Programming (ROP) is a code-reuse exploit technique that chains short instruction sequences ending in RET to execute arbitrary computation without injecting new code.
- appsec№ 545
Intel CET
Intel CET (Control-flow Enforcement Technology) is a CPU feature combining a hardware shadow stack and Indirect Branch Tracking (IBT) to block ROP, JOP and COP exploits.
● See also
- № 581KASLR