You don't need to be a security expert to build with AI, but you do need to understand what can go wrong. Here are 10 common security mistakes AI-generated apps make, and at the end of this article, I'll share a Claude skill I've been using to help catch them.

So let's go down the list shall we?

1. Broken Access Control

At number one we have broken access control, which is not only the most common issue I have run into, it's also OWASP's number one: A01:2021 Broken Access Control. In OWASP's dataset, 94% of applications were tested for some form of broken access control, and it had over 318,000 occurrences, which is more than any other category. It's that big of a problem!

It's definitely the most serious issue. This can come in different ways and forms, but the most common versions of this that I have seen are: escalating roles from free to pro without paying and accessing/editing resources you don't own.

The Fix:

Your server must check on every request that the authenticated user is actually allowed to touch the resource they're asking for. Never trust the client to enforce this. But better yet, if your database can support policies, implement them. Supabase, for example, allows you to set Row Level Security, which lets you write policies directly in Postgres that filter which rows each user can read or write (typically keyed off auth.uid()). That way, even if your app code forgets a check, the database itself refuses to hand over rows that don't belong to that user. Consider also the idea zero trust but for your app, where you give the least amount of access to everyone and simply go up from there.

2. No Server Side Validation

Endpoints can receive essentially any JSON request body and the app will handle it. What happens when a malicious user sends a Shakespeare novel instead of their first name? It might be funny, but it's not something you want to be dealing with. And what if it's not a long text but a malicious HTML/script tag that your website then renders on the page? Now you're open to XSS.

The nastier version I've seen is when update endpoints accept any field you send them, allowing you to update properties on the database schema without any checks. If there's no validation on your "update account" endpoint, a user can simply upgrade their free account to pro for free (which is still part of broken access control and pertains to permission checks). Or what if you have AI features paywalled, but you give a user three tries to try out the AI feature? Well with no request validation, you can simply send a request like so

curl -X PATCH https://myapp.com/api/me \
  -H "Authorization: Bearer <your-own-token>" \
  -d '{"plan": "pro", "aiCreditsRemaining": 999999}'

This won't just affect your database, it can also affect third-party APIs that you're using. If you aren't validating the user's input when you send their request to your AI chat feature, you could be inadvertently sending the user's submitted Shakespeare novel to your AI API, and thus costing you money now!

The fix

Every endpoint should have a dedicated schema validation tool (such as zod, Joi, whatever your stack uses) on what the request body should look like. Also: reject unknown fields instead of silently accepting them (zod's .strict(), Joi's stripUnknown), enforce maximum lengths on every string, and never spread the raw request body into a database update. Instead, explicitly pick the fields a user is allowed to change.

3. No Rate Limiting

It's bad enough that people are now sending Shakespeare novels to your app, but what if they wrap this around a looping script and hit all your sensitive endpoints? Your API being called 10,000 times a minute? What will happen exactly? The targets for this are login, password resets, your AI feature endpoints, and anything that can send an e-mail or SMS.

The fix

Implement server-side rate limiting, such as a fixed-window, sliding-window, or token-bucket limiter per IP and per user, or at least pull in a dependency that can perform some simple level of it (like express-rate-limit if you're on Node). Even bare minimum is better than nothing because you can at least prevent a catastrophic disaster. If you have an endpoint that can send e-mails and/or text messages (e.g., e-mail invite, 2FA), make sure these endpoints have a 30 second to 1 minute cooldown between each request being sent.

Services like Upstash Redis (with their @upstash/ratelimit library) can be enabled on your application in a few lines and give you a sliding-window counter per IP and user.

4. Bad file upload validation

Some apps I have seen contain some social media aspect, whether it's uploading photos, videos, audio, etc.

What's stopping someone from uploading a virus? Sure, it won't execute on your server, but your app just became a distribution point: someone downloads an innocent-looking "photo" and it's an executable. Or worse... some "image" formats can carry scripts, such as an SVG with JavaScript inside or an HTML file with a renamed extension, and if your app serves that file back and the browser renders it, you've got stored XSS.

The Fix

When uploading media, check file types by actual content (magic bytes), not just extension; enforce size limits; strip metadata; and serve uploads from object storage on a separate domain with the correct Content-Type so the browser never renders them as pages. That combo should kill most stored-XSS risks, which is the realistic threat for most apps.

If your app's whole job is distributing files to other users (photo sharing, a marketplace, general file hosting), add actual malware scanning on top.

5. Enumeration & Injection Vulnerabilities

We've all heard of SQL Injection. Funny enough I have seen AI do an OK job here, though it still pops up.

The more interesting one I keep finding are in search and filter features. If your API takes a filter object from the client and passes it more or less directly into a database query, you're letting the client write your queries for you. An attacker can send a custom filter that reveals data that should never be reachable, like listing every admin account, or every user with a gmail address. It's a bit surprising how often this one has come up.

The Fix

Never pass client-supplied query structures to the database. Allowlist which fields and operators are filterable on the server, and build the query yourself from those. We can also look at the queries being sent and think: how can we manipulate this query by changing the initial request? We can go from there on fixing it.

6. Secrets Leaked

This one is not so much the AI's fault, since it's usually pretty good here. It's the humans. I can barely understand the justification if you have a private repo. But if that repo ever goes public, rotate those keys immediately. And remember: git history is forever. Deleting the line in a new commit does nothing; the key is still in the history. Rotation is the only fix.

We solved this problem ages ago. Please never hardcode API keys in the UI or the backend.

The Fix

Secrets live in environment variables or a proper vault service, and turn on secret scanning (GitHub push protection or gitleaks) so keys never make it into history in the first place.

7. Exposing PII Data

This one is a huge problem!! Your API is probably returning more fields than the client needs, and the big one is the customer's e-mail.

If you're really trying to get users to use your app, you need to make sure you're not sending your customers' sensitive data out on your API. This is especially common on social type apps of course. E-mail is the biggest problem.

The Fix

You're more than likely storing a customer's e-mail; tell your AI to look for PII data and see where it's being returned on the API. The less information you can provide the better off you are.

8. No Logging & Monitoring

Picture this: your app stops working, but how long was it down for? An attacker could be hammering your API and you won't even know that it's happening.

Or maybe a user hits a problem and reaches out to you for support, but nobody can see what happened, because there's no error tracking or metrics. Monitoring isn't only for attackers; it's how you support real users. You won't be able to help them at all, and now that bug is off to the wind, never to be understood again.

The Fix

At minimum, an error tracker (Sentry or similar), an uptime check, and alerts. This is such an easy thing to add that will save you a TON of problems in the future.

9. No Backups

This is essential especially if you're going to be iterating a lot on your app. If you get real users, and the AI suddenly decides to do a massive database migration because you are adding or changing a new feature. It will hopefully generate a proper runbook, but things don't always go smoothly. If you accidentally destroy your database or environment, the quickest way to restore is with a backup. And make sure you are testing them too, because if you have it but never test it, then you don't really know if it's going to work.

The Fix

Ask your AI what your backup strategy should be for your system. Everything is different, but something needs to be in place. This especially must be done once you have live customers because you do not want to have data loss; it's how you lose customers and their trust!

Once in place, have automated scheduled backups, and actually run a restore once in a while to prove they work.

10. Supply Chain Vulnerabilities

AI can and will install dependencies that are old, sometimes with known CVEs. It picked those versions because they were common in its training data, not because they're current.

The Fix

Setup Dependabot (or Renovate), and run npm audit in CI. Neither is perfect, but either one is miles ahead of no CVE checking at all.

Bonus Interesting Ones

There are more but I think that this covers the vast majority of them, at least the most important ones. I do have some bonus ones that I included that didn't really fit being a major mistake/security concern.

Admin Panels

Admin UI living in the same app as customer-facing code. I find it interesting how common this is, and there's nothing wrong with it per se. Now this isn't something the AI dreamed up on its own; the user explicitly asked for an admin panel, and the AI simply bolted it onto the existing app. But imagine if you have an admin panel and your app contains all the 10 issues I mentioned? If someone could just easily escalate their privileges to admin, they have access to all the sensitive data and controls that your admin panel exposes. This just introduces another unnecessary attack vector in your app.

The Fix

This is more personal opinion, but this is how I would solve it: A separate project entirely, with its own credentials and deployment at something like admin.myapp.com, reachable only over the company (or your own) VPN. Yes, it still needs proper auth (VPN access alone isn't authorization) but at least the admin portal isn't sitting on the public internet. If that's too much work, then at least make it a separate app on a separate domain or subdomain so the two don't share the same attack surface.

No staging site

I don't think this is necessary at first, but it definitely should be once you have real users. It can help you have a dedicated place to test and break your app, and avoid the "testing in prod" that you're probably doing already.

The Fix

Ask your AI what existing structures you have for a staging environment, what steps you need to take to create one, and what it would look like based on your current architecture. Come up with a plan (you can ask AI to help here) on how to have a proper code change -> staging -> test -> production deployment flow. You can set up a dedicated pipeline on GitHub or wherever and have it deploy to a dedicated subdomain of the domain name you own.

No Privacy Policy, Terms of Service nor GDPR

This is the more legal "boring" side of things... but it's important to have.

You need to explain to the user how you are using their data and for what, especially on apps that are charging money.

On the GDPR front, you more than likely will end up having European users, so it should be taken into account. GDPR applies based on where your users are, not where your company is, and fines can reach €20 million or 4% of global annual revenue, whichever is higher. Start with baby steps.

The Fix

Use a policy generator (Termly, iubenda, GetTerms, or similar) to get a baseline Privacy Policy and Terms of Service up, and link them in your footer and signup flow. Only collect the data you actually need; the less PII you store, the less you have to worry about. For GDPR specifically: add cookie consent if you're running analytics or trackers, and make sure a user can request a copy of their data and have their account deleted (the rights of access and erasure).

Conclusion + My Skill

Every chat box carries the same disclaimer: "AI can make mistakes." These mistakes above are what that looks like in practice, and they will ship with your app unless you go looking for them. To make that easier, I made an AI skill that checks for all ten: vibechecktech-skills. This doesn't replace a proper human code review, audit review and/or pen test, but it will surface these issues so you can act on them before your users (or someone worse) find them first.

Initially the project started off with Yahoo Fantasy, and I got a lot of great feedback to add more features and more fantasy leagues. So naturally the project grew to support Sleeper and ESPN. This year I spent a good amount of time doing a full rewrite of the UI, and I'm quite happy with it.

Yahoo Fantasy is the main platform I use for the league with my close friends. But this year, Yahoo decided to make a major change to their developer API. Instead of simply registering a developer account and registering your app, you must now request access to the API.

This wouldn't be a problem, if not for the fact that Yahoo can take weeks or even months to respond back. So now it can be a bit of a waiting game until you hear back from them. In the meantime, my app along with other developer apps don't work at all with Yahoo Fantasy, since they have revoked API access to existing apps.

Why has all this changed?

More and more API providers are starting to gatekeep their APIs, and... I definitely understand why.

These developer tools came with a gentleman's agreement kind of trust. They knew for a fact a human would go in and register and make these accounts. But nowadays, I'm sure these platforms are getting absolutely slammed by more crawlers and scrapers for AI companies. They can't rely on the inherent "good nature" of API consumers anymore, so they have to gate access.

I think it makes sense why they gatekeep; they are being forced to. It's a resource drain on their compute, it's also gatekeeping their data from LLMs simply reading it for free, and it's also a way to stop people from using their API to build, say, an AI tool that uses their data when they'd rather build and monetize it themselves.

But that's the danger with building your house on someone else's land. While these decisions from Yahoo make sense against companies and apps trying to monetize their data, hobbyists like me just trying to make fun and helpful tools get caught in the middle of this and have to wait until my broken app works again... hopefully.

These engineers I've worked with aren't the only ones of course, there is the broader online tech community of software engineers as well: Reddit, Hacker News, (...and to an extent, LinkedIn). I genuinely enjoy reading articles and blog posts from these experts in the software community, and the information and knowledge they have to share about a particular subject is not only interesting, but can be an incredible learning tool as well, especially for niche subjects.

However, with AI, these voices and opinions are being replaced by a statistical machine instead.

"Oh, I'm Reading AI"

Now we all have used ChatGPT or some LLM tooling before. Come on, we kind of just know how it sounds. An LLM response usually has telltale signs. I see this especially in LinkedIn and Reddit, where the last sentence contains some engagement bait: "Anyone else? Curious if...". Even odder is when the original poster replies back to comments with an AI response: "That's fair...", or "You're absolutely right...".

At this point, whenever I read a post online now, I can just tell that it's written by some LLM. And as I am reading a post, I have something in the back of my brain that triggers a reflex: "Oh, I'm reading AI". Once that comes to mind, I kind of just... die inside lol... This isn't something from an expert, this is just an output from an AI, which I could just be asking myself. Now yes, I understand that that is not the case for everyone; some people, believe it or not, can actually write professionally. But in this day and age, it's harder and harder to tell what's really from a person or not, so rightfully so I will assume that a post is just an AI post if it "quacks and walks like a duck".

And look, I also fully acknowledge that you can definitely get it to not sound too much like AI. But more often than not, the posts I read just seem like they are copying and pasting the very first LLM response and calling it a day, not even trying to modify it nor make it their own voice again.

Just Post What You Want To Say

I definitely am not opposed to using AI, in fact I did have it help me with this very post in itself (could you tell?), but I didn't have it write the whole thing for me.

Don't let the AI think for you, let it work for you and let it be an extension of your thought, not a total replacement. I know that it's efficient and comfortable to just let it type for you, but I would much rather read a typo filled and grammatically incorrect blog post than another generic AI post.

If you have something to share, just write it out and post it. Have AI structure it better for you or don't use it at all, but please just post your own thoughts. I want to hear what you have to say.

Conclusion

I thought of many different comparisons... but I guess you can compare this to a painting. If I see a beautiful painting and you tell me it’s AI, I will feel gross about it, why is that? It's because there’s no human value to it. I don’t attach my kids' scribbles on the fridge because they’re a work of art, it’s because a human made it. Imagine if I hung AI art on my fridge instead? That’s how I feel when reading your AI generated posts.

So as AI becomes more and more a part of our lives and work, I think there will be a genuine want and need for "human only" input and feedback again, it will almost seem nostalgic in a way. Yes, I believe that AI is useful and great, and yes I believe that it is here to stay. Just don't let it replace your voice.

Update: I've made a few changes to help clarify a few things. First off, I just wanted to say that everything I'm sharing here is just based on my own opinions and personal preferences when it comes to using custom Node.js Errors. I hope it'll be useful to you too! I've also tweaked the error classes and code examples to make them a bit better - hope this post helps!

A small yet powerful tool that I believe every Node.js developer should use and know about is the ability to create custom errors within their application.

Creating custom errors gives us a few advantages:

1. Allows us to create more specific unit tests for error scenarios.
2. Including extra debugging information in the Error class, not limiting us to just Error.message.
3. Categorizing errors promptly to pinpoint their exact location of occurrence.

Defining a Custom Error

To define a custom error class, simply extend the Error class. See some examples below.

class InvalidInputError extends Error {
  constructor(message, statusCode) {
    super(message);
    this.name = this.constructor.name;
    this.statusCode = statusCode;
  }
}
class DatabaseError extends Error {
  constructor(message, statusCode, originalError) {
    super(message);
    this.name = this.constructor.name;
    this.statusCode = statusCode;
    this.originalError = originalError;
  }
}

Now when we extend this class, we can have control over what new and additional properties we can send. So whether it's to rethrow an error or capture it in a log, the custom error class can give us extra information on what is going on.

To use the custom error, simply throw it the same way as the built-in error class.

const { InvalidInputError, DatabaseError } = require('../errors');

function validateUser(user) {
  if (!user || !user.email || !user.email.includes('@')) {
    throw new InvalidInputError('Invalid user email');
  }

  // This is just an example
  try {
    await someDatabaseCall(user.email);
  } catch(err) {
    throw new DatabaseError('Database Error Occurred', 500, err);
  }

}

In this example, we throw a custom error class for invalid user input, and we use a try-catch block to handle any errors that may be thrown during the database call. We throw a typical error message so don't divulge too much information to the end user on what exactly happened.

It's important to pass the original error when throwing a custom error class like DatabaseError. This way, we don't lose any information on the original cause of the error. Of course this may vary depending on the type of error you're handling. In the case of InvalidInputError, we don't need to pass the original error because we're not re-throwing it from the database call.

Benefit 1: Specific Unit Tests

Imagine if we were to write a unit test for the method above. How would we test for the error case if we simply threw new Error() for the input validation or re-threw the error from the database call? Well, we'd have to catch the error based on the string value.

describe('validate user existing', () => {
  it('should throw an error if the user cannot be found in the database', async () => {
    expect(() => await validateUser('someemail@email.com').to.throw(/Database Error Occurred/))
  });
});

But with the added benefit of our custom error, we can write a much cleaner unit test that doesn't check for a string value, but rather the class type.

const { DatabaseError } = require('../errors');

describe('validate user existing', () => {
  it('should throw an error if the user cannot be found in the database', async () => {
    expect(() => await validateUser('someemail@email.com').to.throw(DatabaseError));
  });
});

This version of the unit test is much more specific, and we know the exact reason why this error occurred.

Benefit 2: Additional Properties

With us defining the error class now, we can pass as many variables as we need. One valuable variable to include is a timestamp, which can be extremely helpful when errors are captured in your logs.

Moreover, if you have some sort of concept of a tracing/tracking id, you can pass it to the class and the tracing id will be present. This is especially useful if the error is thrown due to an uncaught exception.

class DatabaseError extends Error {
  constructor(message, traceId, statusCode, originalError) {
    super(message);
    this.name = this.constructor.name;
    this.statusCode = statusCode;
    this.originalError = originalError;
    this.date = new Date();
  }
}

const findUserById = async (id) => {
  const traceId = generateRandomUUID(); // some uuid
  logger.info(traceId, "entering database call");
  let user;
  try {
    user = await someDatabaseCall(id);
  } catch (error) {
    logger.info(traceId, "an error occurred during the database query!");
    throw new DatabaseError("Error when getting user.", traceId, 500, error);
  }
  return user;
}

The code above will throw an error like so:

DatabaseError: Error when getting user.
    at script.js:14:9
    at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:530:24)
    at async loadESM (node:internal/process/esm_loader:91:5)
    at async handleMainPromise (node:internal/modules/run_main:65:12) {
  traceId: '56c84a0d-e8da-40e5-8618-f41a8a00cb65',
  date: 2023-02-20T21:35:07.020Z,
  originalError: {Error here}
}

Benefit 3: Quicker to Identify

Notice from the error thrown above, that it contains our class name. This is also a major benefit because right away we can know what type of error this is/where it is coming from.

In this case, since it's a DatabaseError, we know that this pertains to an issue with our database.

If errors aren't categorized correctly, debugging can be a difficult task since developers have to manually analyze the message and stack trace. But by implementing this simple technique, we can simplify the debugging process tremendously by giving us a context clue right away.

Custom Errors That Every Dev Should Have

Generally, I would recommend at least these three types of custom errors. Of course, your use case may vary depending on what you are building.

Startup Error

class StartUpError extends Error {
  constructor(message, traceId, originalError) {
    super(message);
    this.name = this.constructor.name;
    this.originalError = originalError;
    this.date = new Date();
  }
}

This error should be used during application startup, especially when connecting to any backing services, validating environment variables, and other related operations.

API Error

class ApiError extends Error {
  constructor(message, traceId, originalError, statusCode = 500) {
    super(message);
    this.name = this.constructor.name;
    this.traceId = traceId;
    this.originalError = originalError;
    this.statusCode = statusCode;
    this.date = new Date();
  }
}

These errors apply to everything that will be sent via our API and will also include any HTTP error status codes.

You can also get extra fancy and extend this base ApiError. This way you can have consistent HTTP error classes depending on the type of HTTP error you will be sending.

class NotFoundError extends ApiError {
    constructor(resource, traceId, originalError) {
        super(`Could not find resource ${resource}`, traceId, originalError, 404);
    }
}

Application Error

class ApplicationError extends Error {
  constructor(message, traceId, originalError) {
    super(message);
    this.name = this.constructor.name;
    this.originalError = originalError;
    this.date = new Date();
  }
}

I use Application Errors for "everything else" and/or custom error failure cases that aren't necessarily meant for a user. Additionally, in this example I call the class ApplicationError, but I prefer to use the name of my application. So if the name of my app is called "Quiz App", I'd call it "QuizAppError".

You'll notice that this class is the same as the StartUpError. But what I am taking advantage of here is the name of the class. When this error is thrown, I know that it is a specific error case that I have handled and caught, so it will contain the additional debugging information I have added.

Conclusion

Creating custom errors allows your application to be more flexible and easier to understand. Additionally, implementing them doesn't require much extra effort, and I can guarantee you that you, you're coworkers, and as well as your users, will appreciate these explicit and detailed error messages.

Resources and Tools

• Node.js Error Documentation
• ChatGPT for proof reading this post.

Blog Posting Site Code