Delivery Speed, Generated Code, and the Security Debt It Creates

Juan Pablo Mora 4 min read

Delivery Speed, Generated Code, and the Security Debt It Creates

TLDR: Generated code produces working features quickly and skips security decisions at the same speed. Open endpoints, tokens in the browser, passwords in API responses, sequential IDs with no ownership check: these are not AI failures, they are review failures. Speed is fine. Unreviewed authorization code reaching production users is not.


The Speed Is Real. So Is What Gets Skipped.

AI-assisted development has changed how fast a working feature ships. A developer can go from requirement to functional endpoint in minutes. That speed is genuine and, in most cases, a real competitive advantage for teams under pressure.

The security tradeoff is equally real. Generated code is trained on the entire public corpus of existing code, which means it reproduces the most common patterns, including the insecure ones. It produces CRUD endpoints without permission checks because most of the code it learned from had no permission checks. It returns full model instances in API responses because that is the default in most frameworks. It stores tokens in localStorage because that is the example in most tutorials.

The tool does what it was trained to do. Shipping it without a human reviewing the authorization layer first is where the problem starts.


What a Recent Audit Found

In a recent audit of a custom platform built quickly with AI assistance, several of these patterns appeared together in the same codebase. None were intentional. All were review failures. These are the five we find most often:

Open permission classes. The endpoint exists, the route is registered, and the framework default ("allow any authenticated user") is in place. No one verified whether that endpoint should be scoped to the owning account.

Passwords and tokens in serializer output. The generated serializer returns every field on the model. The password hash, the API key, the session token: all present in the JSON response, readable by anyone who hits the endpoint.

Sequential record IDs treated as secrets. The code assumes that if the user does not know the ID, they cannot access the record. That assumption fails the moment someone runs a loop. We covered this failure in detail in Access Control Gaps in Custom Business Platforms.

Refresh tokens that do not revoke on logout. The logout endpoint clears the client-side cookie. The server-side token remains valid. Anyone who captures the token before logout retains access until expiry.

File access without ownership checks. The upload works. The download endpoint returns the file to any authenticated user who knows the path.

That audit surfaced three of the five in the first hour of testing. Guatemala Digital, an unrelated engagement documented separately, came from a different era of code and a different entry point, but the same root cause: access boundaries that were never verified before the system went live.


This Is a Process Problem

Teams that use AI-assisted development well ship faster, iterate more, and spend less time on boilerplate. The issue is not the tool. The issue is when in the process a human reviews the output.

Generated code makes that review more necessary, not less. A developer writing a permission check from scratch makes a deliberate decision at each step. A developer accepting generated code inherits a set of assumptions they may not have examined. The examination needs to happen before the code reaches users.

A security-focused code review is not a full audit. It is a targeted pass over the highest-risk surface: authorization on list and detail endpoints, serializer output, session and token behavior, file access paths. On a typical custom feature, that review takes an hour. On a platform that has never had one, it takes longer and the findings scale accordingly.


The Questions to Ask Before Sign-Off

If you are evaluating a vendor who uses AI-assisted development, or reviewing a system already in production, these are the questions that surface this risk:

  • Who reviews new endpoints for authorization before they ship?
  • What fields does your API return by default on a user or record model?
  • How does logout work server-side: does the token remain valid after the client clears it?
  • How are file download paths protected after upload?

A vendor who cannot answer the first question has not built the review into their process.

At nimble., authorization review runs inside every sprint, not as a pre-launch checkpoint, because finding these issues at the end of a project costs significantly more than building with them in mind from the start. Our approach to custom software security covers the specific patterns we enforce at the framework level.

If you want a targeted application security testing pass on a system that was built fast, get in touch.