Scheme-ing For Secure Client API Access; DuckDB Novelty List; JetBrain’s Take On JavaScript Best Practices In 2024

A bit of API security, a new way to perform an old idiom with one of the best tools ever made, and some guidance on how to think about the JavaScript you write in 2024+ await readers of this mixed-up edition of the Drop.

TL;DR

(This is an AI-generated summary of today’s Drop using Ollama + llama 3.2 and a custom Modelfile.)

• Take some time this week to make sure you use https:// (https is the URI/URL scheme part) in all API requests from your API client(s). (https://jviide.iki.fi/http-redirects)
• We’ve covered how to surface novel items in one file when compared to a different file, but I’m steadily moving some operations with longstanding (or, new!) Linux CLI tools over to DuckDB. This particular idiom is fairly concise and blazingly fast in DuckDB. (https://gitlab.com/-/snippets/4764853)
• JavaScript development has evolved significantly since its inception in 1995, and modern best practices emphasize cleaner, more maintainable code. Many folks have many takes on “best”, and here’s what JetBrains has to say on the matter in 2024: (https://blog.jetbrains.com/webstorm/2024/10/javascript-best-practices-2024/)

Scheme-ing For Secure Client API Access

This section could just be one-sentence: “Take some time this week to make sure you use https:// (https is the URI/URL scheme part) in all API requests from your API client(s).”

Before I add some light expository to that, let’s take a look at the post which inspired this section.

In “Your API Shouldn’t Redirect HTTP to HTTPS“, the author asserts the onus is on API providers to “do the right thing” by bending over backwards to ensure all API requests from clients are made over TLS (i.e., https).

The core issue is deceptively simple: many APIs silently redirect HTTP requests to HTTPS endpoints, creating a dangerous security hole that masks client mistakes. When clients accidentally use http:// instead of https:// in API calls, credentials and sensitive data get transmitted in plaintext before the secure connection is established.

Rather than helpfully redirecting HTTP traffic, APIs should immediately fail any unencrypted requests. This aligns with the fail-fast principle — clients should know immediately when they’ve made a potentially dangerous mistake rather than having it silently handled.

The author conducted a modest survey of major API providers which revealed that many popular services like GitHub, GitLab, Slack, and numerous others still implement HTTP-to-HTTPS redirects. Some providers like Stripe, Google Cloud, and Shopify properly reject unencrypted connections with error responses.

The issue stems partly from conflating web application and API security best practices. While HTTP-to-HTTPS redirects make sense for user-facing web applications (especially with strict transport security/HSTS), they’re actively harmful for APIs where clients typically don’t maintain security state like browsers do.

Think of HTTP-to-HTTPS API redirects as a well-meaning bouncer who, instead of stopping people without ID, walks them through the front door to get their ID checked inside. Sure, they eventually get properly verified, but they’ve already walked through the secure area. The proper approach is to check credentials at the perimeter and immediately turn away anyone not meeting the security requirements. This isn’t just about being strict — it’s about ensuring developers can’t accidentally expose sensitive data through a simple typo.

In truth, the author’s strong guidance that services immediately invalidate any API credentials sent over plaintext is technically correct. Since the credentials are easily sniffable en-route from client to server, both the caller and API provider are at some risk. But the risks associated with the leakage of these secrets are just one risk out of many. Immediately invalidating the credentials could cause harm to both the caller/caller’s org/biz (who may depend on the third-party API for major business process functionality) and the operator of the API, who may lose customers if they take such a draconian approach.

A decent middle ground — during the path to migrating to a pure HTTPS API experience on the part of the API service — would be to batch notifications to the caller about the weak caller’s configuration, so they can take the appropriate steps of generating new keys/creds and invalidating the old ones (plus triaging the usage of the old credentials to see if they were, indeed, stolen and used inappropriately).

I assert that ensuring HTTPS is used in all cleint calls is primarily on us. It’s trivial to add git hooks to check that URLs baked into code or configs are using HTTPS (said checks can be augmented with allow-listing use of HTTP in internal URLs, provided the internal usage is on a segmented network). It’s further easy to schedule jobs to monitor configuration elements placed in cloud (or local) config stores.

Teams can draft and publish standards that dictate the mandatory use of HTTPS. They can build client API wrappers that abstract away the contextually mandatory use of HTTPS as well.

In either case (client API user or API operator), you should definitely “take some time this week to make sure you use https:// (https is the URI/URL scheme part) in all API requests from your API client(s).”

DuckDB Novelty List

We’ve covered how to surface novel items in one file when compared to a different file, but I’m steadily moving some operations I would have done with longstanding (or, new!) Linux CLI tools over to DuckDB. This particular idiom is fairly concise and blazingly fast in DuckDB. Here’s one way to do it.

The nvd-cves.txt is a list of all current NVD CVEs, pulled from VulnCheck’s spiffy (and free!) Community API.

The existing-cves.txt is a list of CVEs I’ve already processed.

I need to know which news ones I need to process, and this is one way to do it in DuckDB:

$ duckdb -noheader -list -c "
	WITH new_cves AS (
	  FROM read_csv('nvd-cves.txt', header=false) SELECT column0 AS cve
	),
	old_cves AS (
	  FROM read_csv('existing-cves.txt', header=false) SELECT column0 AS cve
	)
	SELECT new_cves.cve 
	FROM new_cves 
	LEFT JOIN old_cves ON new_cves.cve = old_cves.cve
	WHERE old_cves.cve IS NULL;
"

It’s super-fast, and will scale to larger files better than comm, awk, or grep solutions.

There’s a “robust” and generic version of that wrapped up in this Bash script, which takes the files as input, and performs additional pre-flight checks.

JetBrain’s Take On JavaScript Best Practices In 2024

JavaScript development has evolved significantly since its inception in 1995, and modern best practices emphasize cleaner, more maintainable code. Many folks have many takes on “best”, and here’s what JetBrains has to say on the matter in 2024:

• The language has moved away from var in favor of block-scoped let and const declarations. This shift provides more predictable behavior and reduces unexpected scoping issues that were common with function-scoped var.
• JavaScript now supports proper class syntax instead of the older prototype-based approach. Classes provide cleaner syntax for object-oriented programming, including private fields using the # prefix. This enables true encapsulation rather than relying on underscore conventions for private members.
• The async/await pattern has largely replaced promise chains and callback patterns. This approach makes asynchronous code read more like synchronous code and significantly improves error handling through standard try/catch blocks.
• Modern JavaScript provides powerful methods for working with objects and arrays. Object.entries(), Object.values(), and Object.keys() simplify object manipulation, while Array.isArray() offers reliable array type checking across different contexts.
• Strict equality (===) should be preferred over loose equality (==) to avoid unexpected type coercion. When working with conditional statements, explicit comparisons are better than relying on JavaScript’s truthy/falsy behavior.
• The Map data structure should be used when non-string keys are needed or when maintaining key order is important. Unlike plain objects, Map can use any value as a key and preserves insertion order.
• For precise calculations, especially in financial contexts, the built-in Number type should be avoided due to IEEE 754 floating-point limitations. Libraries like decimal.js or big.js provide the necessary precision.
• The built-in Intl API now provides robust support for formatting dates, numbers, and currencies across different locales, often eliminating the need for external formatting libraries.
• JSDoc comments have become increasingly important for code documentation and editor support. They provide clear type information and improve the development experience through better autocompletion and type checking.
• Modern JavaScript environments now include built-in test runners. Node.js version 20 and above ships with a native test runner, reducing the need for external testing frameworks in simpler projects.

They go into far more detail and have plenty of code examples, so make sure to head on over there to get all the crunchy details.

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev ☮️