Security on dplabs — Software Engineering & Technology Consultancy

Secure by Default: APIs That Are Hard to Misuse

Mon, 29 Jun 2026 00:00:00 +0000

Security by default is a design principle, not a feature list. An API is secure by default when using it correctly produces secure behavior automatically, and producing insecure behavior requires deliberate effort.

Most security failures are not the result of sophisticated attacks on well-designed systems. They’re the result of developers using APIs incorrectly, making incorrect assumptions about what defaults are safe, or forgetting to add security checks that should have been built in.

The Security Risks of AI-Enabled Applications

Tue, 21 Apr 2026 00:00:00 +0000

Integrating AI into applications introduces security risks that traditional application security doesn’t address. Most security frameworks were designed for deterministic systems. LLMs are not deterministic — their outputs depend on inputs in ways that are difficult to predict, test, or constrain.

This doesn’t mean AI applications are inherently insecure. It means you need to think about security differently when LLMs are in the loop.

The Core Problem: LLMs Process Text as Instructions

In a conventional application, there’s a clear distinction between code and data. A SQL injection attack tries to blur that boundary — to get user input interpreted as SQL commands. You prevent it by parameterizing queries, by treating user input as data rather than code.

Security Is an Architecture Concern

Mon, 26 May 2025 00:00:00 +0000

Security gets treated as a feature set: authentication, authorization, input validation, encryption. Implement those features and the system is secure. This framing is wrong and produces systems that are secure in obvious ways while vulnerable in non-obvious ones.

Security is an emergent property of architectural decisions: where trust boundaries are placed, how data flows between components, what permissions components have, how failures are handled. These decisions are made during design, not during a security review at the end.

Authentication vs Authorization: Two Problems People Keep Conflating

Mon, 24 Mar 2025 00:00:00 +0000

“Authentication” and “authorization” are often used interchangeably. They’re not the same problem, they’re not the same solution, and conflating them produces security architectures that fail in predictable ways.

The Definitions That Matter

Authentication: verifying who someone is.

A request is authenticated when the system has verified that the claimed identity (user, service) is legitimate. After authentication, you know who is making the request.

Authorization: determining what someone is allowed to do.