Rust on guy@secdev.uk

Rust Security Code Review Guide

Sat, 04 Apr 2026 00:00:00 +0000

1. Introduction

I put this guide together as a structured approach to security-focused code review for Rust applications. Whether you’re just starting to identify security vulnerabilities in Rust code or you’re an experienced developer looking for a language-specific checklist, I’ve tried to make it useful at both levels.

Rust’s ownership model, borrow checker, and type system prevent entire classes of bugs, use-after-free, null pointer dereferences, and data races in safe code. However, what I found when I started reviewing Rust codebases is that unsafe blocks, third-party crate choices, and application-level logic errors still introduce serious vulnerabilities. What follows covers manual review strategies, common anti-patterns, recommended tooling, and vulnerability patterns organised by class, with cross-references to the intentionally vulnerable examples in this project.

Rust Learning Guide - Anti-Patterns

Wed, 11 Mar 2026 00:00:00 +0000

Overview

The antipatterns.rs module Source Code File demonstrates 15 common Rust mistakes and their correct solutions. I put this together because I noticed the same patterns coming up, especially from developers (myself included) fighting the borrow checker instead of working with it.

Anti-Patterns Covered

1. Unnecessary .clone() Everywhere

❌ Cloning to avoid borrow checker
✅ Use references (&T) instead

2. Using .unwrap() in Production

❌ Crashes program on error
✅ Return Result<T, E> and handle gracefully

3. Returning References to Local Variables

❌ Dangling references (won’t compile)
✅ Return owned data or use ‘static lifetime

4. Using String When &str Would Work

❌ Forces caller to own String
✅ Accept &str - works with both

5. Ignoring Compiler Warnings

❌ Unused mut, unused variables
✅ Listen to the compiler

6. Using Indices Instead of Iterators

❌ C-style loops can panic
✅ Use iterators - safer and clearer

7. Manually Implementing What Traits Provide

❌ Manual equality checks
✅ #[derive(PartialEq, Debug, Clone)]

8. Using Vec When Array Would Work

❌ Heap allocation for fixed-size data
✅ Use arrays [T; N] for stack allocation

9. Nested match/if let Instead of Combinators

❌ Deeply nested matching
✅ Use .map(), .filter(), .and_then()

10. Using Mutex When Not Needed

❌ Mutex in single-threaded code
✅ Just use regular variables

11. Collecting Iterator Just to Iterate Again

❌ Unnecessary intermediate collection
✅ Chain iterators directly

12. Using Deref Coercion as Inheritance

❌ Simulating inheritance with Deref
✅ Use composition explicitly

13. Panicking in Library Code

❌ panic!() crashes caller’s program
✅ Return Result and let caller decide

14. Using format! When to_string() Works

❌ Overkill for simple conversions
✅ Use .to_string() for clarity

15. Implementing Default Manually

❌ Manual new() constructor
✅ Implement Default trait

Key Principle

Work WITH Rust’s ownership system, not against it.

Rust Learning Guide - Core Concepts Explained

Fri, 06 Feb 2026 00:00:00 +0000

I put this guide together to explain each Rust concept demonstrated in the example programs, with comparisons to C and Java. The more I dug into Rust’s design decisions, the more I appreciated how much thought went into making safety guarantees that don’t cost you performance. Here’s what I found.

Supporting Code Examples

1. OWNERSHIP SYSTEM

What it is: Rust’s core memory management system. Every value has a single owner, and when the owner goes out of scope, the value is dropped (freed). This was the concept that took the longest to click for me, but once it did, everything else fell into place.

Rust Security: When unsafe Breaks the Promise

Sat, 11 Oct 2025 00:00:00 +0000

I love Rust. I genuinely do. Its ownership system, borrow checker, and type system wipe out entire classes of vulnerabilities at compile time, use-after-free, double-free, data races, null pointer dereferences, buffer overflows. But here’s the thing: Rust gives you an escape hatch called unsafe, and when it’s used incorrectly, it reintroduces every single vulnerability that Rust was designed to prevent. The more I dug into real-world Rust codebases, the more I found this happening. Beyond unsafe, Rust has its own quirky set of security pitfalls: integer overflow behaviour that differs between debug and release builds, FFI boundaries that trust C code unconditionally, and logic errors that the type system simply cannot catch. In this post, I want to walk through the Rust-specific anti-patterns that break the safety promise.

Race Conditions

Sat, 16 Aug 2025 00:00:00 +0000

Race conditions (CWE-362) are, in my opinion, the most insidious class of security bugs you’ll encounter. They occur when the behaviour of a program depends on the relative timing of concurrent operations, and at least one of those operations modifies shared state. The window between a check and a subsequent use of the checked value, the classic time-of-check to time-of-use (TOCTOU) pattern, is the most exploited form, but races also show up in counter increments, balance updates, session management, and file operations. What makes race conditions uniquely dangerous is their non-determinism: the bug may not manifest in thousands of test runs, then appear under production load when two requests arrive within microseconds of each other. I want to walk through race conditions in Python, Go, Java, and Rust, from the obvious unprotected counter to the subtle channel-based ordering assumption that passes every test but fails under contention.

Integer Overflow

Sat, 02 Aug 2025 00:00:00 +0000

Integer overflow (CWE-190) is one of those bugs that I find endlessly fascinating because of how quietly destructive it is. It happens when an arithmetic operation produces a value that exceeds the maximum (or falls below the minimum) representable value for the integer type. In C and C++, signed integer overflow is undefined behaviour, the compiler is free to assume it never happens, and optimizations built on that assumption can eliminate bounds checks entirely. Unsigned overflow wraps around silently. Go and Java define overflow as wrapping (two’s complement), which prevents undefined behaviour but still produces incorrect results that lead to security vulnerabilities: undersized allocations, bypassed length checks, and negative indices into arrays. Rust panics on overflow in debug mode but wraps in release mode by default, creating a gap between testing and production behaviour that caught me off guard when I first started digging into Rust’s safety guarantees. I want to walk through integer overflow across C, C++, Rust, Go, and Java, from the textbook multiplication overflow to the subtle cast truncation that can survive expert review.

Out-of-Bounds Writes

Sat, 21 Jun 2025 00:00:00 +0000

Out-of-bounds writes (CWE-787) are the single most dangerous class of memory corruption vulnerabilities on the SANS/CWE Top 25, and they’ve held that position for years. The reason is clear once you dig into the mechanics: writing past the end of a buffer can overwrite return addresses, function pointers, vtable entries, and adjacent heap metadata, giving attackers arbitrary code execution. Unlike higher-level languages where the runtime catches array index violations, C and C++ silently corrupt memory, and the consequences may not manifest until thousands of instructions later. Even Rust, with its ownership model, is vulnerable when unsafe blocks bypass the borrow checker. In this post I’ll dissect out-of-bounds writes in C, C++, and Rust, from the classic strcpy overflow to the subtle off-by-one in pointer arithmetic that can survive expert review.

Authentication Failures

Sat, 26 Apr 2025 00:00:00 +0000

Authentication is the front door of every application, and OWASP A07 documents how often that door is left unlocked. When I started digging into authentication failures, I realised they go far beyond weak passwords, they encompass hardcoded credentials compiled into binaries, brute-force attacks with no rate limiting, password hashes that can be reversed in seconds, and reset flows that hand tokens directly to attackers. These patterns show up in production regularly, sometimes in the same application. This post covers three CWEs across Python, Java, Go, and Rust: CWE-798 (Use of Hard-Coded Credentials), CWE-287 (Improper Authentication), and CWE-307 (Improper Restriction of Excessive Authentication Attempts).

Cryptographic Failures That Pass Code Review

Sat, 01 Mar 2025 00:00:00 +0000

Cryptographic code is uniquely dangerous, and it’s one of the areas I find most challenging to review. The reason is simple: it can be completely wrong and still appear to work perfectly. A broken hash function still produces a hash. A weak cipher still encrypts and decrypts. A predictable random number generator still generates numbers. The application runs, tests pass, and the vulnerability sits quietly until an attacker exploits it. In this post, I want to walk through the cryptographic failures that routinely survive code review across Python, Java, Go, and Rust, from the obvious use of MD5 to the subtle misuse of otherwise strong primitives.

XSS Is Not Just a JavaScript Problem

Sat, 01 Feb 2025 00:00:00 +0000

Cross-site scripting gets framed as a front-end problem a lot, something that happens in JavaScript and gets fixed with JavaScript. But the more I dug into this, the clearer it became that XSS vulnerabilities almost always originate on the server side, in whatever language is generating the HTML. I’ve found XSS in Python templates, Java JSPs, Go’s html/template misuse, Rust web frameworks, and server-rendered JavaScript. The language you write your backend in determines which XSS patterns you’ll run into and which ones will sneak past your review.

Command Injection Beyond os.system

Sat, 18 Jan 2025 00:00:00 +0000

When most developers hear “command injection,” they think of os.system() in Python or Runtime.exec() in Java. Those are the textbook examples, and most teams know to avoid them. But the more I researched this topic, the more I realised that command injection surfaces through dozens of less obvious APIs across every language, subprocess pipes, shell expansions, backtick operators, and even seemingly safe exec functions that become dangerous with the wrong arguments. This is one of my favourite vulnerability classes to dig into because the attack surface is so much wider than people realise. Let me walk you through command injection patterns across seven languages, from the obvious to the genuinely subtle.