Rust for Secure Backend Development: A Critical Review and Extended Vulnerability Comparison with Node.js and Django

Rust for Secure Backend Development: A Critical Review and Extended Vulnerability Comparison with Node.js and Django Md Zarzees Uddin Shah Chowdhury

arXiv:2608.22624v1 [cs.PL] 23 Aug 2026

Virginia Tech Blacksburg, VA, USA zarzees5075@vt.edu

Rabib Jahin Ibn Momin

Rifat Shahriyar

Bangladesh University of Engineering and Technology Dhaka, Bangladesh

Bangladesh University of Engineering and Technology Department of Computer Science and Engineering Dhaka, Bangladesh

Abstract

pointer dereferences address long-standing vulnerabilities pervasive in systems programming. However, while Rust’s safety mechanisms are widely celebrated, a systematic evaluation of its security posture in industrial contexts—particularly in critical infrastructure adhering to standards like IEC 62443 remains underexplored. Gasiba and Amburi [5] investigate Rust’s efficacy in mitigating software vulnerabilities compared to C, C++, and Java, languages entrenched in industrial practice. Despite Rust’s advancements, conflating safety with security risks overlooking non-memory-related flaws, such as logic errors, insecure configurations, and web-layer vulnerabilities (e.g., CrossSite Scripting). Their research addresses this gap through a multi-faceted methodology:

The Rust programming language is widely credited with eliminating entire classes of memory-safety and concurrency vulnerabilities, but the security implications of adopting it in practice extend well beyond memory safety. This paper presents a critical review of prior work on Rust’s security posture in industrial settings [5], and extends that analysis in a direction the original study did not cover: backend web development. We first assess the strengths and limitations of the existing vulnerability classification of Rust against C, C++, and Java under the SANS Top 25, OWASP Top 10, and the 19 Deadly Sins of Software Security frameworks, identifying gaps including limited empirical validation, a small interview sample, and the absence of a secure development lifecycle discussion. We then contribute an original comparison of Rust against Node.js and Django using the same three-level classification (Rare and Difficult, Safeguarded, Unprotected), supported by side-by-side code experiments for out-of-bounds writes (CWE-787), use-after-free (CWE416), and race conditions (CWE-362). Our results indicate that Rust’s compile-time guarantees dominate at the systems layer, while managed backend frameworks offer stronger built-in defenses at the application layer, suggesting that Rust adoption in web contexts requires complementary safeguards rather than reliance on language-level safety alone.

• Literature Review: Analyzing academic and gray literature (2010–2023) on Rust’s security model, vulnerabilities, and tooling. • Expert Interviews: Gathering insights from industry professionals with over a decade of experience in secure software development. • Vulnerability Mapping: Aligning Rust’s protections with frameworks like SANS Top 25, OWASP Top 10, and the 19 Deadly Sins of Software Security. • Tool Analysis: Evaluating Static Application Security Testing (SAST) tools for Rust against mature ecosystems like Java and C++.

Keywords: Rust Programming Language, Secure Software Development, Memory Safety, Vulnerability Analysis, Static Application Security Testing (SAST), Industrial Cybersecurity, CWE/SANS/OWASP Mapping, Unsafe Code Mitigation, Concurrency Safety, Secure Coding Practices

1

Their findings reveal that while Rust eliminates 24% of SANS Top 25 vulnerabilities (e.g., buffer overflows, race conditions) through language design, 48% remain unaddressed (e.g., path traversal, insecure authentication). Notably, vulnerabilities often stem from misuse of unsafe code blocks or design-level oversights unrelated to memory safety. Compared to C/C++ (no inherent protections) and Java (garbagecollected memory safety), Rust strikes a balance between low-level control and safety but necessitates complementary secure coding practices. In this paper we critically review that study and extend it. Our contributions are twofold. First, we assess the strengths

Introduction

The Rust programming language, emerging in 2010, has rapidly gained prominence in industrial software development due to its emphasis on memory safety and concurrency. With adoption in critical systems such as the Linux Kernel and Android, Rust positions itself as a robust alternative to traditional languages like C and C++. Its compile-time guarantees against memory corruption, data races, and null 1

Chowdhury, Momin, and Shahriyar

and limitations of their methodology and vulnerability classification (Section 5), and reproduce representative code experiments to verify the classification decisions they report. Second, we extend the comparison beyond systems languages to backend web development, evaluating Rust against Node.js and Django under the same three-level scheme (Section 6). As industries increasingly prioritize cybersecurity resilience, understanding Rust’s role—as both a safeguard and a potential risk—is critical for shaping future secure development paradigms.

2

that no language can fully automate vulnerability prevention. Jacoby et al. [12] validated the three-point vulnerability classification (RD/SG/UP) by demonstrating the sufficiency of Likert-style scales for such analyses. Rust CVEs and Mitigations. The Rust Security Response WG addresses vulnerabilities like CVE-2021-42574 [17] (Unicode trojans) and CVE-2022-46176 [18] (Cargo SSH vulnerabilities). Amburi’s PoC code [1] demonstrates exploitable weaknesses (e.g., SQL injection) even in Rust, reinforcing the need for complementary safeguards. Collectively, these works contextualize Rust’s strengths but leave gaps in systematic vulnerability analysis across industrial standards. The study we review [5] bridges this by mapping Rust’s protections to SANS Top 25, OWASP Top 10, and the 19 Deadly Sins [9], while addressing tooling and awareness challenges specific to industrial adoption. None of this prior work, however, evaluates Rust against the managed backend stacks that dominate web development, which is the gap our extension in Section 6 addresses.

Related Work

Research on Rust’s security has evolved alongside its industrial adoption. Sible et al. [20] conducted a foundational analysis of Rust’s memory and concurrency safety, highlighting limitations such as memory leaks and the need for holistic security practices. Wassermann et al. [22] expanded this by emphasizing vulnerabilities arising from misaligned design assumptions and advocating for ecosystem maturity. Their work stresses the importance of analyzing real-world vulnerabilities, even without source code access, to mitigate risks in Rust-based systems. Qin et al. [15] empirically studied unsafe code usage in Rust projects, revealing that while developers minimize unsafe blocks, memory-safety bugs often stem from interactions between safe and unsafe code. Their findings underscore the complexity of Rust’s lifetime system and the risks of integrating unsafe code for performance. Xu et al. [23] further analyzed all Rust common vulnerability and exposures (CVEs), concluding that memory-safety challenges persist despite Rust’s compile-time guarantees, particularly when developers bypass safety mechanisms.

3

Methodology of the Reviewed Study

We summarize the methodology of Gasiba and Amburi [5] here, since our critical analysis in Section 5 assesses it directly and our extension in Section 6 reuses its classification scheme. Their study evaluates Rust’s security capabilities through a multi-phase approach, combining qualitative and quantitative analyses, and addresses two research questions: RQ1: To what extent does Rust mitigate vulnerabilities compared to C, C++, and Java? RQ2: How effective are existing tools and practices for secure Rust development in industrial contexts? 3.1

Security Standards and Industrial Guidelines. Industrial adoption of Rust necessitates alignment with standards like IEC 62443 [10] for critical infrastructure and ISO/IEC TR 24772 [11] for secure coding. The Common Weakness Enumeration (CWE) [13] framework provides a unified taxonomy of software weaknesses, while ANSSI’s guidelines for Rust [3] offer tailored rules to address its safety-security interplay.

Research Design

The methodology comprises four stages: • Literature Review: They analyzed academic and gray literature (2010–2023) from ACM, IEEE Xplore, and Google Scholar using keywords like "Rust Security" and "SAST Tools". This included foundational works by Qin et al. [15] on unsafe code and Gasiba et al. [7] on secure coding awareness. • Expert Interviews: Semi-structured interviews were conducted with five industry security experts (10+ years of experience) and two open-source Rust contributors. Discussions focused on Rust’s adoption challenges, vulnerability patterns, and tooling gaps. • Vulnerability Mapping: They mapped Rust’s protections to three frameworks: 1. SANS Top 25 [19] and CWE [13] for system-level weaknesses. 2. OWASP Top 10 [14] for application-layer vulnerabilities. 3. 19 Deadly Sins of Software Security [9] for design flaws.

Tools and Ecosystem Maturity. The Rust ecosystem includes tools like RustSec [16] for tracking crate vulnerabilities and SAST tools listed in Analysis Tools [2]. Google’s integration of Rust into Android [8] exemplifies its industrial use to mitigate memory-safety bugs. However, maturity gaps persist compared to Java/C++ ecosystems, which leverage tools like SonarQube [21] for compliance. Secure Coding Practices and Awareness. Gasiba et al. [7] identified a gap between developers’ intent to follow secure coding guidelines and their practical knowledge. Their work inspired platforms like Sifu [6], which gamifies cybersecurity education. Bagnara et al. [4] explored the undecidability of secure coding rules (e.g., input validation), emphasizing 2

Rust for Secure Backend Development

Table 1. SANS Top 25 CWE vs. Protection Levels in Rust. Reproduced from Gasiba and Amburi [5].

• Static Analysis: They evaluated Rust’s SAST tools (e.g., Clippy, RustSec) against Java (SonarQube [21]) and C++ (cppcheck) ecosystems. 3.2

CWE ID Short Description RD SG UP CWE-787 Out-of-bounds Write • CWE-79 Cross-site Scripting • CWE-89 SQL Injection • CWE-20 Improper Input Validation • CWE-125 Out-of-bounds Read • CWE-78 OS Command Injection • CWE-416 Use After Free • CWE-22 Path Traversal • CWE-352 CSRF • CWE-476 NULL Pointer Dereference • CWE-190 Integer Overflow • CWE-798 Improper Authentication • CWE-259 Use of Hard-coded Credentials • CWE-362 Missing Authorization • CWE-77 Command Injection • CWE-119 Buffer Overflow • CWE-276 Incorrect Default Permissions • CWE-918 Server-Side Request Forgery • CWE-362 Race Condition • CWE-611 Improper Restriction of XXE • CWE-94 Code Injection • Protection Levels: Rare and Difficult (RD) 24%, Safeguarded (SG) 28%, Unprotected (UP) 48%.

Vulnerability Classification

They categorized vulnerabilities using a three-point scale inspired by Jacoby et al. [12]: 1. Rare and Difficult (RD): Fully mitigated by Rust’s design (e.g., buffer overflows [23]) unless unsafe blocks are used. 2. Safeguarded (SG): Partially addressed by Rust or dependent on libraries (e.g., SQL injection via rusqlite [1]). 3. Unprotected (UP): Require external mitigations (e.g., insecure authentication [3]). 3.3

Validation

The authors developed Proof-of-Concept (PoC) code [1] demonstrating vulnerabilities in Rust (e.g., command injection, TOCTOU). These were analyzed using SAST tools to assess detection efficacy. Industrial experts validated findings against IEC 62443 [10] compliance requirements.

4

Findings of the Reviewed Study

This section summarizes the results reported by Gasiba and Amburi [5]. Tables 1, 2, 3, and 4 reproduce their vulnerability mappings across industrial standards, and all percentages quoted below are theirs. The code listings in Section 4.3 are our own, written to independently check two of the classification decisions they report. Our original results are presented separately in Section 6. 4.1

4.3.1 CWE-787: Out-of-Bounds Write Vulnerability Classification. Rust’s ownership and borrowing system prevents out-of-bounds writes at compile time, unless unsafe blocks are used.

SANS Top 25 Vulnerabilities in Rust

Table 1 reproduces their categorization of Rust’s protection levels for the SANS Top 25 CWEs. They report that Rust fully mitigates 24% of these vulnerabilities (e.g., buffer overflows [23]) through compile-time checks, while 48% remain unprotected (e.g., path traversal).

1 2

fn main () { let mut arr = [1 , 2 , 3 , 4 , 5];

3

// Attempt to write out of bounds ( will cause a compile - time error ) arr [5] = 6; // Index 5 is out of bounds for an array of length 5

4

5

4.2

Comparison with C, C++, and Java

6

Table 2 reproduces their classification for C, C++, and Java, highlighting Rust’s advantages over C/C++ (no inherent protections) and Java (partial safeguards via garbage collection). In their scheme, Rust mitigates all memory-safety CWEs (e.g., CWE-119) unless unsafe is used. 4.3

}

Explanation: • Rust’s compiler enforces bounds checking, preventing out-of-bounds writes. • If unsafe blocks are used, the responsibility shifts to the programmer, but this is discouraged unless absolutely necessary. C does not provide built-in memory safety mechanisms, making out-of-bounds writes a common vulnerability.

Verifying the Classification with Code

To check the classification decisions above rather than accept them at face value, we implemented and compiled representative programs for two entries in Table 1: CWE-787 and CWE-362. The listings in this subsection are our own. In both cases the observed compiler and runtime behavior matched the protection level reported in [5].

1

# include < stdio .h >

2 3 4

3

int main () { int arr [5] = {1 , 2 , 3 , 4 , 5};

Chowdhury, Momin, and Shahriyar

Table 2. SANS Top 25 Protection Levels in C, C++, and Java. Reproduced from Gasiba and Amburi [5].

2

4

C++ Java UP RD SG UP RD SG UP CWE-787 • • • CWE-79 • • • CWE-89 • • • CWE-20 • • • CWE-125 • • • CWE-78 • • • CWE-416 • • • CWE-352 • • • CWE-434 • • • CWE-476 • • • CWE-502 • • • CWE-190 • • • CWE-798 • • • CWE-287 • • • CWE-259 • • • CWE-862 • • • CWE-77 • • • CWE-306 • • • CWE-119 • • • CWE-276 • • • CWE-918 • • • CWE-362 • • • CWE-400 • • • CWE-611 • • • CWE-94 • • • Protection Levels: C: RD 0%, SG 0%, UP 100%; C++: RD 0%, SG 24%, UP 76%; Java: RD 20%, SG 28%, UP 52%. CWE

C RD SG

5

8 9

10 11

12 13

10 11

15 16

17

19

4.3.2 CWE-362: Race Condition Vulnerability Classification. We classify the Race Condition vulnerability in Rust, C, C++, and Java based on their concurrency safety mechanisms: Rust’s ownership and borrowing system, combined with its concurrency primitives, makes race conditions rare and difficult to occur.

printf ("% d \ n " , arr [5]) ; // May print garbage or crash return 0;

7

fn main () { let counter = Arc :: new ( Mutex :: new (0) ) ; 6 let mut handles = vec ![]; 4 5

8 9

11 12 13 14 15

19

# include < iostream >

for _ in 0..10 { let counter = Arc :: clone (& counter ) ; let handle = thread :: spawn ( move || { let mut num = counter . lock () . unwrap () ; * num += 1; }) ; handles . push ( handle ) ; }

16

C++ provides some safeguards (e.g., std::vector with bounds- 17 18 checked access), but raw arrays and pointers are still unsafe. 1

use std :: sync ::{ Arc , Mutex }; use std :: thread ;

3

10

• C does not enforce bounds checking, leading to undefined behavior if an out-of-bounds write occurs. • This makes C programs highly vulnerable to memory corruption attacks.

}

Explanation: • C++ provides safeguards like std::vector::at(), which performs bounds checking and throws exceptions for out-of-bounds access. • However, raw arrays and pointers in C++ are still unsafe and require careful handling to avoid vulnerabilities.

2

Explanation:

return 0;

18

// Out - of - bounds write ( no compile - time or runtime checks ) arr [5] = 6; // Undefined behavior , may corrupt memory

}

// Unsafe access with raw arrays ( no bounds checking ) int raw_arr [5] = {1 , 2 , 3 , 4 , 5}; raw_arr [5] = 6; // Undefined behavior , may corrupt memory

14

8 9

// Safe access with bounds checking ( throws an exception if out of bounds ) try { arr . at (5) = 6; // Throws std :: out_of_range exception } catch ( const std :: out_of_range & e ) { std :: cerr << " Out of bounds access : " << e . what () << std :: endl ; }

7

1

7

int main () { std :: vector < int > arr = {1 , 2 , 3 , 4 , 5};

6

5 6

# include < vector >

3

20

4

for handle in handles { handle . join () . unwrap () ; }

Rust for Secure Backend Development

println !(" Result : {}" , * counter . lock () . unwrap () ) ;

21

22

}

9 10

Explanation: • Rust enforces strict concurrency rules at compile time, preventing data races. • The Mutex and Arc types ensure safe shared access to data across threads. C++ provides concurrency primitives (e.g., std::mutex), but race conditions are still common if not used correctly.

11 12 13 14 15 16 17

for ( Thread t : threads ) { t . join () ; }

18

# include < iostream > 2 # include < thread > 3 # include < vector >

19

4

22

1

5

threads [ i ] = new Thread (() -> { for ( int j = 0; j < 1000; j ++) { synchronized ( Main . class ) { // Safeguard : synchronized block counter ++; } } }) ; threads [ i ]. start () ; }

8

20 21

System . out . println (" Result : " + counter ) ; // Correct due to synchronization }

int counter = 0;

6

23

void increment () { 8 for ( int i = 0; i < 1000; i ++) { 9 counter ++; // Race condition : unprotected access 10 } 11 }

24

7

}

Explanation: • Java provides built-in mechanisms like synchronized blocks and the java.util.concurrent package to prevent race conditions. • However, improper use of these mechanisms can still lead to race conditions.

12 13 14

int main () { std :: vector < std :: thread > threads ;

15

for ( int i = 0; i < 10; i ++) { threads . emplace_back ( increment ) ; }

16 17 18

4.4

As shown in Table 3, they find that Rust partially safeguards 50% of the OWASP Top 10 vulnerabilities (e.g., injection via libraries) but offers no protection against design-level flaws (A04, A05).

19

for ( auto & t : threads ) { t . join () ; }

20 21 22

OWASP Top 10 Mapping

23

25 26

Table 3. OWASP Top 10 Mapping to Rust Protection Levels. Reproduced from Gasiba and Amburi [5].

std :: cout << " Result : " << counter << std :: endl ; // Likely incorrect due to race conditions return 0;

24

OWASP Vulnerability RD SG UP A01: Broken Access Control • A02: Cryptographic Failures • A03-Injection • A04-Insecure Design • A05-Security Misconfigura• tion A06-Vulnerable and Outdated • Components A07-Identification and Authen• tication Failures A08-Software and Data In• tegrity Failures A09-Security Logging and • Monitoring Failures Protection Levels: RD 0%, SG 50%, UP 50%.

}

Explanation: • C++ provides tools like std::mutex, but it is up to the programmer to use them correctly. • Without proper synchronization, race conditions are common in C++ programs. Java provides built-in concurrency safeguards (e.g., synchronized blocks, java.util.concurrent utilities), but race conditions can still occur if not used properly. 1 2

public class Main { private static int counter = 0;

3 4

5

public static void main ( String [] args ) throws InterruptedException { Thread [] threads = new Thread [10];

6 7

for ( int i = 0; i < 10; i ++) { 5

Chowdhury, Momin, and Shahriyar

4.5

19 Deadly Sins of Software Security

Comprehensive Approach: The methodology incorporates:

Against the 19 Deadly Sins [9], they report that Rust fully mitigates 21% of the “sins” (e.g., buffer overflows) and partially addresses 47% (e.g., SQL injection). The remaining 32% are unprotected and include insecure configurations and SSRF (Table 4).

• Literature review • Interviews with industry security experts • Security standard mapping (CWE, SANS, OWASP) • Static analysis tools

Table 4. 19 Deadly Sins: Security Flaws vs. Protection Levels in Rust. Reproduced from Gasiba and Amburi [5].

This multifaceted approach strengthens the validity of the findings.

Security Flaw RD SG UP Buffer Overflows • Format String Problems • Integer Overflows • SQL Injection • Command Injection • Cross-Site Scripting (XSS) • Race Conditions • Error Handling • Poor Logging • Insecure Configuration • Weak Cryptography • Weak Random Numbers • Using Known Vulnerable Components • Unvalidated Redirects and Forwards • Injection • Insecure Storage • Denial of Service • Insecure Third-Party Interfaces • Cross-Site Request Forgery (CSRF) • Protection Levels: RD: 21%, SG: 47%, UP: 32%.

Comparative Analysis: The study effectively compares Rust with C, C++, and Java, providing structured vulnerability classification using the categories: Rare and Difficult (RD), Safeguarded (SG), and Unprotected (UP). This categorization aids in understanding Rust’s security posture.

4.6

Small Sample Size in Interviews: Only five industry experts and two students were interviewed. A broader sample size would provide a more comprehensive perspective on Rust’s security challenges.

Discussion of Real-World Vulnerabilities: By analyzing past Common Vulnerabilities and Exposures (CVEs) in Rust, the study underscores that while Rust mitigates memory safety issues, it remains vulnerable to other forms of software security risks. Contribution to Industry and Academia: The paper raises awareness of Rust’s security pitfalls and provides insights for both researchers and industry practitioners, facilitating informed decision-making regarding Rust adoption. 5.2

Limited Empirical Evidence: The study lacks large-scale empirical testing. Conducting real-world security testing on Rust applications would enhance the robustness of the conclusions.

CVEs and SAST Tool Effectiveness

Rust’s security advisories address critical CVEs like CVE2022-46176 [18] (Cargo SSH flaw). They further observe that SAST tools for Rust (e.g., Clippy) lag behind Java’s SonarQube [21] in detecting logic flaws, and report that only 6 of 400+ Rust CVEs are actively tracked by RustSec [16].

5

Overemphasis on Memory Safety : While memory safety is a crucial aspect, the study could have further explored nonmemory vulnerabilities, such as improper authentication and insecure cryptographic implementations.

Critical Analysis

Having summarized the methodology and findings of Gasiba and Amburi [5], we now assess that work directly. This section presents our own evaluation of its contributions and shortcomings. 5.1

Weaknesses and Limitations

Lack of Industry Case Studies: The absence of real-world case studies from companies using Rust for security reasons limits practical applicability. Including case studies would provide tangible insights into Rust’s effectiveness.

Strengths of the Research

Timeliness and Relevance: The research is highly relevant given Rust’s increasing adoption in the software industry, particularly in security-critical areas such as the Linux Kernel and Android development. The study contributes to an area with limited systematic security analysis.

Missing Discussion on Secure Development Lifecycle : The research does not address how Rust fits into a broader secure software development lifecycle (SDLC). Analyzing Rust’s role in security testing, deployment, and CI/CD pipelines would be beneficial. 6

Rust for Secure Backend Development

6

Our Experiment

6.1

Experimental Comparison: Rust vs other Backend Language (Node.js and Python Django)

2

buffer [15] = 255; // Out - of - bounds write ( No immediate error , but unsafe )

3

• Python (RD): Python’s dynamic memory management prevents direct memory manipulation, making out-of-bounds writes impossible in pure Python code.

To extend the authors’ research on Rust’s security in comparison to other programming languages, we introduce an additional analysis focusing on backend development. While the original study compares Rust against C, C++, and Java, our work expands this comparison by incorporating Node.js and Django, two widely used backend technologies. Our primary objective is to evaluate how well Rust protects against the SANS Top 25 Common Weakness Enumeration (CWE) security vulnerabilities compared to these backend alternatives. We analyzed the 6 among 25 vulnerabilities shown in the table 5 We categorize security protections using the same three-level classification system—Rare and Difficult (RD), Safeguarded (SG), and Unprotected (UP)—to maintain consistency with the original research. Through this extended study, we provide insights into Rust’s security strengths and weaknesses within web and backend development, highlighting how it differs from frameworks and languages like Node.js (JavaScript-based) and Django (Python-based). This analysis is particularly relevant for industry professionals considering Rust for backend applications, helping them weigh security implications alongside performance and scalability factors.

1 2

buffer = bytearray ( b " ABC ") # buffer [5] = 65 # IndexError : index out of range

3

Use After Free (CWE-416) • Rust (RD): Rust’s ownership model ensures that memory is automatically deallocated when it goes out of scope, preventing use-after-free errors. The compiler enforces strict rules to ensure no references to freed memory exist. 1

let x = Box :: new (42) ; // drop ( x ) ; // Explicitly deallocates memory 4 // println !("{}" , x ) ; // Compile - time error : use of moved value 2 3

5

• Node.js (UP): JavaScript/Node.js relies on garbage collection to manage memory. However, native modules or external libraries can introduce use-after-free vulnerabilities if they improperly handle memory.

Table 5. Vulnerability Classification for Rust, Node.js, and Django (Python Core Language). This comparison is our own contribution.

let buffer = Buffer . alloc (10) ; buffer . fill (0) ; 3 buffer = null ; // Memory is freed 4 // Accessing buffer here would lead to undefined behavior 1 2

CWE ID 787 125 416 190 119 362

6.2

Description Out-of-bounds Write Out-of-bounds Read Use After Free Integer Overflow Buffer Overflow Race Condition

Rust RD RD RD RD RD RD

Node.js UP UP UP UP UP UP

Python RD RD RD RD RD SG

5 6

• Python (RD): Python’s garbage collector manages memory automatically, preventing use-after-free errors in pure Python code. Once an object is no longer referenced, it is deallocated safely.

Explanation with Code

Out-of-bounds Write (CWE-787)

1

• Rust (RD): Rust’s ownership model and compile-time checks prevent out-of-bounds writes by ensuring all memory accesses are within bounds.

2

1

6

2 3

3 4

obj = MyClass () obj = None # Garbage collector deallocates memory 7 # Accessing obj here would raise an error 5

let mut arr = [1 , 2 , 3]; // arr [5] = 10; // Compile - time error : index out of bounds

8

4

9

• Node.js (UP): JavaScript/Node.js does not inherently protect against out-of-bounds writes when interacting with native modules or external libraries. 1

class MyClass : def __init__ ( self ) : self . value = 42

Race Condition (CWE-362) • Rust (RD): Rust’s ownership model prevents data races at compile time by enforcing strict rules about

const buffer = Buffer . alloc (10) ; 7

Chowdhury, Momin, and Shahriyar

mutable and shared references. This makes race conditions rare and difficult to occur in safe Rust code. 1 2

12 13

use std :: sync ::{ Arc , Mutex }; use std :: thread ;

14 15

3 4 5

for _ in range (10) : thread = threading . Thread ( target = increment ) threads . append ( thread ) thread . start ()

16

let counter = Arc :: new ( Mutex :: new (0) ) ; let mut handles = vec ![];

17 18

6

for thread in threads : thread . join ()

19

for _ in 0..10 { 8 let counter = Arc :: clone (& counter ) ; 9 let handle = thread :: spawn ( move || { 10 let mut num = counter . lock () . unwrap () ; 11 * num += 1; 12 }) ; 13 handles . push ( handle ) ; 14 } 7

20

print ( counter ) to lock )

# Always prints 10 ( safe due

21 22

7

Discussion

Taken together, the findings of Section 4 underscore Rust’s transformative potential in secure software development while exposing critical gaps that challenge its industrial adoption. Below, we contextualize those findings, compare them with prior work, and outline implications for academia and industry.

15

for handle in handles { handle . join () . unwrap () ; 18 } 19 // Safe from race conditions due to Mutex 16 17

20 21

7.1

• Node.js (UP): JavaScript/Node.js is single-threaded, which reduces the likelihood of race conditions. However, asynchronous operations can still lead to race conditions if shared state is not properly synchronized.

4

Rust’s compile-time guarantees eliminate entire classes of vulnerabilities (e.g., buffer overflows, data races) that plague C/C++ systems [15]. However, the reported mapping shows that 48% of SANS Top 25 vulnerabilities remain unaddressed (Table 1), echoing Wassermann et al. [22], who caution against conflating memory safety with holistic security. For instance, unsafe code, used in 34% of Rust crates [23], reintroduces risks akin to C, particularly when developers misapply lifetimes or bypass borrow-checker constraints.

6

7.2

1

let counter = 0;

2

setTimeout (() = > { counter ++; 5 } , 100) ; 3

setTimeout (() = > { 8 console . log ( counter ) ; // May print 0 or 1 depending on timing 9 } , 100) ; 7

• Python (SG): Python provides synchronization primitives like locks (threading.Lock) to handle race conditions in multi-threaded programs. Developers must explicitly use these tools to safeguard against race conditions.

7.3

import threading

2 3 4

7 8 9

counter = 0 lock = threading . Lock () def increment () : global counter with lock : counter += 1

10 11

Tooling and Ecosystem Challenges

The immaturity of Rust’s SAST ecosystem, compared to Java’s SonarQube [21] or C++’s Clang Analyzer, exacerbates vulnerability detection gaps. For example, as noted above, only 6 of 400+ Rust CVEs are tracked in RustSec [16], leaving developers reliant on community-driven efforts. This aligns with Gasiba et al. [7], who identified tooling as a critical enabler of secure coding practices. Until Rust’s tooling matures, organizations must supplement SAST with manual audits and adherence to guidelines like ANSSI’s [3].

5 6

Comparative Analysis with Established Languages

While Rust outperforms C/C++ in memory safety, Java’s garbage collection provides comparable protection against memory leaks (Table 2). However, Java’s reliance on runtime checks incurs performance costs, whereas Rust’s zero-cost abstractions align with industrial demands for efficiency [8]. This duality positions Rust as a viable candidate for systems requiring both safety and performance, such as embedded devices or critical infrastructure adhering to IEC 62443 [10].

10

1

Rust’s Security Trade-offs

threads = [] 8

Rust for Secure Backend Development

7.4

Practical Implications

One of the key challenges identified is the relative immaturity of Rust’s static analysis and security tooling compared to more established ecosystems like Java and C++. This gap makes it essential for developers to complement Rust’s safety mechanisms with external security practices, such as secure design patterns, manual audits, and adherence to industry standards like IEC 62443 and OWASP Top 10. For future work, several research directions remain open:

Industries adopting Rust must prioritize: • Training: Addressing Rust’s steep learning curve through targeted programs, as misused lifetimes and ownership rules remain prevalent sources of bugs [15]. • Secure Design: Complementing Rust’s safety with frameworks like OWASP Top 10 to mitigate web-layer flaws (Table 3). • Hybrid Approaches: Using Rust for safety-critical components while leveraging Java/Python for higherlayer logic, as seen in Android [8]. 7.5

• Investigating Rust-specific security risks, including vulnerabilities that arise from misuse of unsafe code and trait object interactions. • Enhancing Rust’s security tooling by developing more robust static analysis tools capable of detecting designlevel security flaws. • Conducting large-scale empirical studies on Rust’s security in industrial applications to assess its effectiveness over time. • Exploring hybrid approaches that integrate Rust with other languages, leveraging its strengths in performance and security while mitigating its limitations in web-layer protections.

Limitations and Future Work

The three-point vulnerability scale (RD/SG/UP) used in the reviewed study and reused in our extension in Section 6, validated by Jacoby et al. [12], simplifies complex interactions but may overlook context-specific risks. Our own extension is further limited by its coverage of only 6 of the 25 SANS CWEs and by the absence of large-scale empirical validation. Future studies should: • Investigate Rust-specific vulnerabilities (e.g., trait object misuse). • Develop SAST tools for IEC 62443 compliance. • Conduct longitudinal studies on Rust’s security in large-scale industrial projects.

8

Overall, Rust continues to be a promising choice for secure software development, particularly in safety-critical and performance-sensitive applications. However, to fully harness its potential, a comprehensive security strategy incorporating both language-level guarantees and best practices from the broader cybersecurity domain is necessary.

Conclusion and Future Work

References

This paper critically reviewed the evaluation of Rust’s security posture in industrial settings presented by Gasiba and Amburi [5], and extended it to backend web development. Their findings, which we reproduced and in two cases verified with our own code experiments, reinforce that Rust’s ownership model, memory safety guarantees, and concurrency mechanisms significantly mitigate vulnerabilities such as buffer overflows, use-after-free errors, and race conditions. However, despite these advantages, Rust does not inherently protect against all security threats, particularly applicationlayer issues such as injection vulnerabilities and insecure authentication. Our critical analysis identified several limitations in their study, most notably its small interview sample, its limited empirical validation, and its omission of the secure development lifecycle. Our own experiments extended that work by evaluating Rust’s security posture in backend development compared to Node.js and Django. The results indicated that while Rust provides strong safeguards against low-level memory vulnerabilities, web frameworks in JavaScript and Python offer built-in protections against high-level security risks, such as cross-site scripting and command injection. This suggests that while Rust is well-suited for system-level security, additional precautions are necessary when using it in web development.

[1] Sathwik Amburi. 2023. Secure Software Development with Rust. doi:10.5281/zenodo.8247155 Last accessed: August 14, 2023. [2] Analysis Tools. 2023. Rust — Analysis Tools. https://analysis-tools. dev/tag/rust Accessed: July 16, 2023. [3] ANSSI. 2023. Programming Rules to Develop Secure Applications With Rust. https://www.ssi.gouv.fr/en/guide/programming-rules-todevelop-secure-applications-with-rust/ Accessed: July 16, 2023. [4] Roberto Bagnara, Alessandro Bagnara, and Patricia M. Hill. 2022. Coding Guidelines and Undecidability. arXiv (2022). arXiv:2212.13933 [5] Tiago Espinha Gasiba and Sathwik Amburi. 2023. I Think This is the Beginning of a Beautiful Friendship - On the Rust Programming Language and Secure Software Development in the Industry. In CYBER 2023: The Eighth International Conference on Cyber-Technologies and Cyber-Systems. IARIA, Porto, Portugal, 19–26. [6] Tiago Espinha Gasiba, Ulrike Lechner, and Maria Pinto-Albuquerque. 2020. Sifu - A Cybersecurity Awareness Platform with Challenge Assessment and Intelligent Coach. Cybersecurity 3, 1 (2020), 24. Accessed: July 16, 2023. [7] Tiago Espinha Gasiba, Ulrike Lechner, Maria Pinto-Albuquerque, and Daniel Méndez. 2021. Is Secure Coding Education in the Industry Needed? An Investigation Through a Large Scale Survey. In 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering Education and Training (ICSE-SEET). 241–252. [8] Google Security Team. 2022. Memory-Safe Languages in Android 13. https://security.googleblog.com/2022/12/memory-safe-languagesin-android-13.html Accessed: July 16, 2023. [9] Michael Howard, David LeBlanc, and John Viega. 2005. 19 Deadly Sins of Software Security: Programming Flaws and How to Fix Them. McGraw-Hill. 9

Chowdhury, Momin, and Shahriyar

[10] International Electrotechnical Commission. 2023. IEC 62443: Industrial Communication Networks - Network and System Security. Technical Report. https://www.iec.ch/blog/understanding-iec-62443 Accessed: July 16, 2023. [11] ISO/IEC. 2019. ISO/IEC TR 24772-1:2019 - Programming Languages — Guidance to Avoiding Vulnerabilities in Programming Languages. Technical Report. https://www.iso.org/standard/71991.html Accessed: July 16, 2023. [12] Jacob Jacoby and Michael S. Matell. 1971. Three-Point Likert Scales Are Good Enough. Journal of Marketing Research 8, 4 (1971), 495–500. doi:10.1177/002224377100800414 [13] MITRE Corporation. 2023. Common Weakness Enumeration (CWE). https://cwe.mitre.org/ Accessed: July 16, 2023. [14] OWASP Foundation. 2021. OWASP Top Ten. https://owasp.org/wwwproject-top-ten/ Accessed: July 16, 2023. [15] Bingyu Qin, Yan Chen, Zheng Yu, Limin Song, and Yuqing Zhang. 2020. Understanding Memory and Thread Safety Practices and Issues in Real-World Rust Programs. In Proceedings of the 41st ACM SIGPLAN Conference on Programming Languages Design and Implementation. 763–779. doi:10.1145/3385412.3386036 [16] Rust Secure Code Working Group. 2023. RustSec Advisory Database. https://rustsec.org/advisories/ Accessed: July 16, 2023.

[17] Rust Security Response Working Group. 2021. Security Advisory for Rustc (CVE-2021-42574). https://blog.rust-lang.org/2022/01/20/cve2022-21658.html Accessed: July 16, 2023. [18] Rust Security Response Working Group. 2023. Security Advisory for Cargo (CVE-2022-46176). https://blog.rust-lang.org/2023/01/10/cve2022-46176.html Accessed: July 16, 2023. [19] SANS Institute. 2023. Top 25 Software Errors. https://www.sans.org/ top25-software-errors/ Accessed: July 16, 2023. [20] J. Sible and D. Svoboda. 2022. Rust Software Security: A Current State Assessment. https://doi.org/10.58012/0px4-9n81 Accessed: July 16, 2023. [21] SonarSource. 2023. SonarQube. Software Tool. https://www. sonarqube.org Accessed: July 16, 2023. [22] G. Wassermann and D. Svoboda. 2023. Rust Vulnerability Analysis and Maturity Challenges. https://doi.org/10.58012/t0m3-vb66 Accessed: July 16, 2023. [23] Hui Xu, Zheng Chen, Mingliang Sun, Yangfan Zhou, and Michael R. Lyu. 2021. Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs. ACM Transactions on Software Engineering and Methodology 31, 1 (2021). doi:10.1145/3466642

10

Related documents

• CVE-2026-103622 — HIGH 8.8#1176051
• TRACTOR Benchmark for Evaluating C to Rust Translators#1051614
• TRACTOR Benchmark for Evaluating C to Rust Translators#1043166
• CVE-2026-47426 — HIGH 7.6#975969
• Beyond Static Guarantees: Measuring the Static-Pass Dynamic-Fail Gap in Security-Sensitive and LLM-Generated Python Code#997752