<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Articles on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/articles/</link>
    <description>Recent content in Articles on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Sat, 04 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/articles/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Rust Security Code Review Guide</title>
      <link>https://www.secdev.uk/blog/articles/rust_security_review_guide/</link>
      <pubDate>Sat, 04 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/articles/rust_security_review_guide/</guid>
      <description>&lt;h2 id=&#34;1-introduction&#34;&gt;1. Introduction&lt;/h2&gt;&#xA;&lt;p&gt;I put this guide together as a structured approach to security-focused code review for Rust applications. Whether you&amp;rsquo;re just starting to identify security vulnerabilities in Rust code or you&amp;rsquo;re an experienced developer looking for a language-specific checklist, I&amp;rsquo;ve tried to make it useful at both levels.&lt;/p&gt;&#xA;&lt;p&gt;Rust&amp;rsquo;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 &lt;code&gt;unsafe&lt;/code&gt; 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Rust Learning Guide - Anti-Patterns</title>
      <link>https://www.secdev.uk/blog/articles/rust_antipatterns/</link>
      <pubDate>Wed, 11 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/articles/rust_antipatterns/</guid>
      <description>&lt;h2 id=&#34;overview&#34;&gt;Overview&lt;/h2&gt;&#xA;&lt;p&gt;The &lt;code&gt;antipatterns.rs&lt;/code&gt; module &lt;a href=&#34;https://github.com/guyadixon/RustLearning/blob/main/src/antipatterns.rs&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;&#xA;    Source Code File&#xA;&lt;/a&gt;&#xA; 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.&lt;/p&gt;&#xA;&lt;h2 id=&#34;anti-patterns-covered&#34;&gt;Anti-Patterns Covered&lt;/h2&gt;&#xA;&lt;h3 id=&#34;1-unnecessary-clone-everywhere&#34;&gt;1. &lt;strong&gt;Unnecessary .clone() Everywhere&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Cloning to avoid borrow checker&lt;/li&gt;&#xA;&lt;li&gt;✅ Use references (&amp;amp;T) instead&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;2-using-unwrap-in-production&#34;&gt;2. &lt;strong&gt;Using .unwrap() in Production&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Crashes program on error&lt;/li&gt;&#xA;&lt;li&gt;✅ Return Result&amp;lt;T, E&amp;gt; and handle gracefully&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;3-returning-references-to-local-variables&#34;&gt;3. &lt;strong&gt;Returning References to Local Variables&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Dangling references (won&amp;rsquo;t compile)&lt;/li&gt;&#xA;&lt;li&gt;✅ Return owned data or use &amp;lsquo;static lifetime&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;4-using-string-when-str-would-work&#34;&gt;4. &lt;strong&gt;Using String When &amp;amp;str Would Work&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Forces caller to own String&lt;/li&gt;&#xA;&lt;li&gt;✅ Accept &amp;amp;str - works with both&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;5-ignoring-compiler-warnings&#34;&gt;5. &lt;strong&gt;Ignoring Compiler Warnings&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Unused mut, unused variables&lt;/li&gt;&#xA;&lt;li&gt;✅ Listen to the compiler&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;6-using-indices-instead-of-iterators&#34;&gt;6. &lt;strong&gt;Using Indices Instead of Iterators&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ C-style loops can panic&lt;/li&gt;&#xA;&lt;li&gt;✅ Use iterators - safer and clearer&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;7-manually-implementing-what-traits-provide&#34;&gt;7. &lt;strong&gt;Manually Implementing What Traits Provide&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Manual equality checks&lt;/li&gt;&#xA;&lt;li&gt;✅ #[derive(PartialEq, Debug, Clone)]&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;8-using-vec-when-array-would-work&#34;&gt;8. &lt;strong&gt;Using Vec When Array Would Work&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Heap allocation for fixed-size data&lt;/li&gt;&#xA;&lt;li&gt;✅ Use arrays [T; N] for stack allocation&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;9-nested-matchif-let-instead-of-combinators&#34;&gt;9. &lt;strong&gt;Nested match/if let Instead of Combinators&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Deeply nested matching&lt;/li&gt;&#xA;&lt;li&gt;✅ Use .map(), .filter(), .and_then()&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;10-using-mutex-when-not-needed&#34;&gt;10. &lt;strong&gt;Using Mutex When Not Needed&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Mutex in single-threaded code&lt;/li&gt;&#xA;&lt;li&gt;✅ Just use regular variables&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;11-collecting-iterator-just-to-iterate-again&#34;&gt;11. &lt;strong&gt;Collecting Iterator Just to Iterate Again&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Unnecessary intermediate collection&lt;/li&gt;&#xA;&lt;li&gt;✅ Chain iterators directly&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;12-using-deref-coercion-as-inheritance&#34;&gt;12. &lt;strong&gt;Using Deref Coercion as Inheritance&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Simulating inheritance with Deref&lt;/li&gt;&#xA;&lt;li&gt;✅ Use composition explicitly&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;13-panicking-in-library-code&#34;&gt;13. &lt;strong&gt;Panicking in Library Code&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ panic!() crashes caller&amp;rsquo;s program&lt;/li&gt;&#xA;&lt;li&gt;✅ Return Result and let caller decide&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;14-using-format-when-to_&#34;&gt;14. &lt;strong&gt;Using format! When to_string() Works&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Overkill for simple conversions&lt;/li&gt;&#xA;&lt;li&gt;✅ Use .to_string() for clarity&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;15-implementing-default-manually&#34;&gt;15. &lt;strong&gt;Implementing Default Manually&lt;/strong&gt;&lt;/h3&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;❌ Manual new() constructor&lt;/li&gt;&#xA;&lt;li&gt;✅ Implement Default trait&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h2 id=&#34;key-principle&#34;&gt;Key Principle&lt;/h2&gt;&#xA;&lt;p&gt;&lt;strong&gt;Work WITH Rust&amp;rsquo;s ownership system, not against it.&lt;/strong&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Rust Learning Guide - Core Concepts Explained</title>
      <link>https://www.secdev.uk/blog/articles/rust_learning_guide/</link>
      <pubDate>Fri, 06 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/articles/rust_learning_guide/</guid>
      <description>&lt;p&gt;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&amp;rsquo;s design decisions, the more I appreciated how much thought went into making safety guarantees that don&amp;rsquo;t cost you performance. Here&amp;rsquo;s what I found.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://github.com/guyadixon/RustLearning&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;&#xA;    Supporting Code Examples&#xA;&lt;/a&gt;&#xA;&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;1-ownership-system&#34;&gt;1. OWNERSHIP SYSTEM&lt;/h2&gt;&#xA;&lt;p&gt;&lt;strong&gt;What it is:&lt;/strong&gt; Rust&amp;rsquo;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Go Learning Guide</title>
      <link>https://www.secdev.uk/blog/articles/go-guide/</link>
      <pubDate>Tue, 06 Jan 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/articles/go-guide/</guid>
      <description>&lt;p&gt;A structured learning guide for developers coming from Java, C, or Python who want to learn Go. I put this together because when I started learning Go myself, I kept wishing for a resource that mapped Go&amp;rsquo;s idioms back to languages I already knew.&#xA;&lt;a href=&#34;https://github.com/guyadixon/GoLearning&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;&#xA;    Github Repo of Code Examples&#xA;&lt;/a&gt;&#xA;&lt;/p&gt;&#xA;&lt;h2 id=&#34;introduction-to-go&#34;&gt;Introduction to Go&lt;/h2&gt;&#xA;&lt;p&gt;Go (also called Golang) was created at Google in 2009 by Robert Griesemer, Rob Pike, and Ken Thompson. It was designed to address the challenges of building large-scale, concurrent software systems while keeping the language simple and productive.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Python Security Code Review Guide</title>
      <link>https://www.secdev.uk/blog/articles/python_security_review_guide/</link>
      <pubDate>Wed, 22 Oct 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/articles/python_security_review_guide/</guid>
      <description>&lt;h2 id=&#34;1-introduction&#34;&gt;1. Introduction&lt;/h2&gt;&#xA;&lt;p&gt;I put this guide together as a structured approach to security-focused code review for Python applications. Whether you&amp;rsquo;re just starting to identify security vulnerabilities in Python code or you&amp;rsquo;re an experienced developer looking for a language-specific checklist, I&amp;rsquo;ve tried to make it useful at both levels.&lt;/p&gt;&#xA;&lt;p&gt;Python&amp;rsquo;s dynamic typing, rich standard library, and extensive third-party ecosystem make it enormously productive, but the more I reviewed Python codebases, the more I realised these same qualities introduce security pitfalls that static analysis alone cannot always catch. 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Java Security Code Review Guide</title>
      <link>https://www.secdev.uk/blog/articles/java_security_review_guide/</link>
      <pubDate>Wed, 09 Jul 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/articles/java_security_review_guide/</guid>
      <description>&lt;h2 id=&#34;1-introduction&#34;&gt;1. Introduction&lt;/h2&gt;&#xA;&lt;p&gt;I put this guide together as a structured approach to security-focused code review for Java applications. Whether you&amp;rsquo;re just starting to identify security vulnerabilities in Java code or you&amp;rsquo;re an experienced developer looking for a language-specific checklist, I&amp;rsquo;ve tried to make it useful at both levels.&lt;/p&gt;&#xA;&lt;p&gt;Java&amp;rsquo;s strong type system, managed memory, and mature ecosystem offer many safety guarantees, but the more I researched Java security, the more I realised the language and its frameworks still expose developers to a wide range of pitfalls including injection, deserialisation, reflection abuse, JNDI injection, and misconfigured XML parsers. 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>C&#43;&#43; Security Code Review Guide</title>
      <link>https://www.secdev.uk/blog/articles/cpp_security_review_guide/</link>
      <pubDate>Mon, 24 Mar 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/articles/cpp_security_review_guide/</guid>
      <description>&lt;h2 id=&#34;1-introduction&#34;&gt;1. Introduction&lt;/h2&gt;&#xA;&lt;p&gt;I put this guide together as a structured approach to security-focused code review for C++ applications. Whether you&amp;rsquo;re just starting to identify security vulnerabilities in C++ code or you&amp;rsquo;re an experienced developer looking for a language-specific checklist, I&amp;rsquo;ve tried to make it useful at both levels.&lt;/p&gt;&#xA;&lt;p&gt;C++ inherits many of C&amp;rsquo;s low-level risks, manual memory management, pointer arithmetic, and the absence of bounds checking, while adding its own layer of complexity through classes, templates, smart pointers, the STL, RAII, and operator overloading. What I find fascinating about C++ security is the duality: when used correctly, features like &lt;code&gt;std::unique_ptr&lt;/code&gt;, &lt;code&gt;std::vector&lt;/code&gt;, and RAII can eliminate entire vulnerability classes. When misused, they create subtle bugs that are harder to spot than their C equivalents, dangling references from moved-from objects, use-after-free through raw pointer aliases to smart-pointer-managed memory, iterator invalidation, and implicit conversions in template code. 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>C Security Code Review Guide</title>
      <link>https://www.secdev.uk/blog/articles/c_security_review_guide/</link>
      <pubDate>Tue, 04 Feb 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/articles/c_security_review_guide/</guid>
      <description>&lt;h2 id=&#34;1-introduction&#34;&gt;1. Introduction&lt;/h2&gt;&#xA;&lt;p&gt;I put this guide together as a structured approach to security-focused code review for C applications. Whether you&amp;rsquo;re just starting to identify security vulnerabilities in C code or you&amp;rsquo;re an experienced developer looking for a language-specific checklist, I&amp;rsquo;ve tried to make it useful at both levels.&lt;/p&gt;&#xA;&lt;p&gt;C&amp;rsquo;s manual memory management, lack of bounds checking, direct pointer arithmetic, and minimal runtime safety make it uniquely prone to entire classes of vulnerabilities that higher-level languages prevent by design. The more I dug into C codebases, the more I appreciated just how many ways things can go wrong, buffer overflows, use-after-free, null pointer dereferences, integer overflows, and format string attacks are all first-class concerns. 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>JavaScript Security Code Review Guide</title>
      <link>https://www.secdev.uk/blog/articles/javascript_security_review_guide/</link>
      <pubDate>Wed, 09 Oct 2024 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/articles/javascript_security_review_guide/</guid>
      <description>&lt;h2 id=&#34;1-introduction&#34;&gt;1. Introduction&lt;/h2&gt;&#xA;&lt;p&gt;I put this guide together as a structured approach to security-focused code review for JavaScript and Node.js applications. Whether you&amp;rsquo;re just starting to identify security vulnerabilities in JavaScript code or you&amp;rsquo;re an experienced developer looking for a language-specific checklist, I&amp;rsquo;ve tried to make it useful at both levels.&lt;/p&gt;&#xA;&lt;p&gt;JavaScript&amp;rsquo;s dynamic typing, prototype-based inheritance, single-threaded event loop with async concurrency, and the vast npm ecosystem make it enormously productive, but the more I dug into JavaScript security, the more I realised these same qualities introduce security pitfalls that static analysis alone cannot always catch. 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.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
