Secure Coding Practices: Language-Specific Rules That Actually Reduce Risk

Why Generic Secure Coding Guides Fail

Most secure coding guides are organized around vulnerability classes: injection, broken authentication, insecure deserialization. This is useful for understanding the problem space but not for fixing actual code. A developer writing Python web views does not experience "injection" as an abstract class; they experience cursor.execute("SELECT * FROM users WHERE id=" + user_id) as a normal-looking query. The guidance that helps is the guidance that names the specific API, the specific pattern, and the specific alternative.

Language-agnostic guidance also misses the exploitability gap. In Python, an insecure YAML load is trivially exploitable to remote code execution. In Go, the equivalent deserialization surface is dramatically smaller because the standard library's JSON decoder does not execute arbitrary code during parsing. The risk profile of the same conceptual problem varies by language runtime, and guidance calibrated for one language misleads developers working in another.

The most dangerous code is code that looks safe to someone who does not know the language's specific attack surface. A developer new to Python who writes yaml.load(data) has written what looks like a simple deserialization call. A developer who knows Python knows that call hands control of code execution to whatever is in data. That gap is what language-specific guidance closes.

Python: The Injection and Deserialization Surface

Python's security risk is concentrated in two areas: SQL injection through string-formatted queries, and unsafe deserialization through pickle and yaml.load. Both are common, both look innocuous to developers unfamiliar with the risk, and both are trivially exploitable.

SQL injection

The vulnerable pattern is string interpolation or concatenation into a query:

# Vulnerable: user_id is attacker-controlled
query = "SELECT * FROM users WHERE id = %s" % user_id
cursor.execute(query)

# Also vulnerable: f-string formatting
cursor.execute(f"SELECT * FROM accounts WHERE owner = '{username}'")

The safe pattern uses parameterized queries, where the database driver handles quoting and escaping:

# Safe: parameterized query
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

# Safe: named parameters (sqlite3, psycopg2)
cursor.execute("SELECT * FROM accounts WHERE owner = :name", {"name": username})

ORM usage does not automatically make queries safe. Django's ORM is safe when you use .filter(), but .extra() and .raw() reintroduce the same vulnerability. The rule is: never concatenate user input into a query string, regardless of the abstraction layer. Python’s re engine has no built-in complexity limit either, which is how a single crafted pattern in NLTK’s Text.findall() could freeze an entire process (CVE writeup) — always set timeouts or use re2 for user-supplied patterns. More language-specific examples of these patterns in production code are documented in Kira’s case studies.

Unsafe deserialization

pickle.loads() executes arbitrary Python code embedded in the serialized data. Any endpoint that accepts pickled data from an untrusted source is a remote code execution vulnerability:

# Critical vulnerability: arbitrary code execution
import pickle
obj = pickle.loads(request.body)  # attacker controls request.body

# Also critical: yaml.load without Loader
import yaml
config = yaml.load(user_supplied_string)  # executes arbitrary Python via !!python/object

The safe alternatives:

# Safe: use JSON for untrusted data
import json
obj = json.loads(request.body)

# Safe: yaml.safe_load restricts to primitive types
config = yaml.safe_load(user_supplied_string)

The rule for Python deserialization is simple: never pass untrusted data to pickle.loads(), pickle.load(), marshal.loads(), or yaml.load() without a safe Loader. If you need to deserialize complex objects from external sources, use a schema-validated format like JSON with explicit type mapping.

JavaScript and Node.js: Prototype Pollution and Template Injection

JavaScript's most distinctive attack surfaces are prototype pollution and server-side template injection. Both are common in Node.js applications, both are frequently introduced through utility library usage that appears safe, and both can escalate to remote code execution or authentication bypass depending on how the affected properties are used downstream.

Prototype pollution

JavaScript objects inherit from Object.prototype. If an attacker can set a property on Object.prototype, that property appears on every object in the process. This matters when application code does checks like if (obj.isAdmin) without verifying that isAdmin was explicitly set on that object rather than inherited from the prototype.

The vulnerability typically arises through deep merge, clone, or path-set utility functions that do not guard against __proto__ or constructor.prototype keys:

// Vulnerable deep merge
function merge(target, source) {
  for (let key of Object.keys(source)) {
    if (typeof source[key] === 'object') {
      merge(target[key], source[key]);
    } else {
      target[key] = source[key];  // sets __proto__ if key is "__proto__"
    }
  }
}

// Attacker sends: {"__proto__": {"isAdmin": true}}
merge({}, JSON.parse(attackerInput));

Safe alternatives include using Object.create(null) for dictionaries that will hold untrusted keys, validating that keys are not __proto__ or constructor, and using structuredClone() for deep copying instead of hand-rolled merge functions.

Server-side template injection

Template engines that evaluate expressions can execute arbitrary JavaScript if the template itself is user-controlled. This is common when developers use template engines to render dynamic email subjects, PDF templates, or notification messages from user-supplied strings:

// Vulnerable: user controls the template string
const template = req.body.emailTemplate;
const rendered = ejs.render(template, { user: currentUser });

// Attacker sends template containing: <%= process.mainModule.require('child_process').execSync('id') %>

The fix is never to treat user-supplied strings as templates. Templates should be stored in the application codebase or in a trusted datastore with strict write controls. User input should only ever populate template variables, not the template structure itself.

Go: Goroutine Leaks and Unsafe Package Misuse

Go's security surface is different in character from Python and JavaScript. The language's strict type system and lack of a global prototype make many classic injection-class vulnerabilities harder to introduce. The risks that are specific to Go are goroutine lifecycle management and the unsafe package.

Goroutine leaks as a denial-of-service vector

A goroutine leak occurs when a goroutine is started but never terminated because the channel it is waiting on is never closed or because a context cancellation is not propagated correctly. In a web service handling many requests, leaked goroutines accumulate and consume memory until the process becomes unresponsive:

// Vulnerable: goroutine leaks if request context is cancelled before ch receives
func handler(w http.ResponseWriter, r *http.Request) {
    ch := make(chan Result)
    go func() {
        ch <- doExpensiveWork()  // blocks forever if nothing reads ch
    }()
    select {
    case result := <-ch:
        render(w, result)
    case <-time.After(5 * time.Second):
        http.Error(w, "timeout", 504)
        // goroutine is still running and blocked on ch
    }
}

The safe pattern propagates context cancellation into the goroutine so it exits when the request is cancelled:

// Safe: goroutine exits when ctx is cancelled
func handler(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    ch := make(chan Result, 1)
    go func() {
        select {
        case ch <- doExpensiveWork():
        case <-ctx.Done():
        }
    }()
    select {
    case result := <-ch:
        render(w, result)
    case <-ctx.Done():
        http.Error(w, "timeout", 504)
    }
}

The unsafe package

Go's unsafe package bypasses the type system and memory safety guarantees that make the language resistant to memory corruption. Code that imports unsafe for performance reasons in hot paths is a recognized pattern, but it requires the same care as C pointer arithmetic. Any function that accepts externally-controlled length parameters and passes them to unsafe.Slice or pointer arithmetic can be exploited to read out-of-bounds memory. Audit every use of unsafe in your codebase and ensure that all length and offset parameters are validated before use.

Java: Deserialization and XML Processing

Java has two attack surfaces that have produced a large share of critical vulnerabilities in enterprise applications: native Java deserialization and XML processing with external entity resolution enabled. Both have well-known fixes that are straightforward to apply, yet both remain common in codebases that have not been audited.

Java deserialization

Java's native ObjectInputStream executes code during deserialization if the serialized data contains instances of classes with dangerous readObject()` implementations. The class does not need to be code you wrote; it needs to exist on the classpath, and many common libraries contain gadget classes that chain together to achieve remote code execution:

// Critical vulnerability: deserializes attacker-controlled bytes
ObjectInputStream ois = new ObjectInputStream(request.getInputStream());
Object obj = ois.readObject();  // executes gadget chains if present on classpath

// Vulnerable: default DocumentBuilder processes external entities
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(inputStream);  // follows DOCTYPE/ENTITY references

// Safe: disable external entities and DOCTYPE
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);
DocumentBuilder db = dbf.newDocumentBuilder();