You added payments last month. Stripe connected, PayFast configured, money is moving. Users are creating accounts and typing their personal information into forms you built. Everything works.
But late at night, when you cannot sleep, your brain whispers questions you cannot answer. Is this actually secure? Could someone steal my customer data? Am I one hacker away from shutting down?
You are not paranoid. You are right to be worried. Security is the one thing AI will not protect you from. AI writes code that works. It does not write code that resists attack. It does not think like someone trying to break your app. It does not know about the OWASP Top Ten or the thousands of ways malicious people will try to exploit your assumptions.
I have seen what happens when founders skip security. I have cleaned up the mess after data breaches. I have helped startups explain to their users why their passwords were exposed. I have watched companies die because someone got into the admin panel.
Let me show you what AI missed and how to secure your application before someone shows you the hard way.
The payment gateway is a target
You integrated PayFast or Stripe or Yoco. You followed the docs. The money flows. But did you think about what happens between your app and the payment provider?
If you are handling raw card details yourself, stop immediately. You do not want to be PCI compliant. You do not want that liability. Offload everything to the payment provider. Use their hosted fields. Use their SDKs. Never let card data touch your server.
But even with the payment provider handling cards, you have work to do. The webhook that Stripe calls when a payment succeeds needs to be secured. Anyone could call that webhook and tell you a payment succeeded when it did not. You need to verify that the request actually came from Stripe. They send signatures for exactly this reason. Verify them.
The same applies to PayFast. They send return URLs with parameters. Anyone could craft those URLs. You need to verify the signature or use their ITN callbacks properly. If you skip this, I can send your customers to a thank you page without paying and you will never know.
Secure payment gateway integration in South Africa is not different from anywhere else except that your users are more vulnerable. Local banking apps have their own security quirks. Users expect you to protect them. Do not be the reason someone gets cleaned out.
API endpoints are open doors
Your app talks to your backend through APIs. Those APIs are sitting on the internet waiting for requests. How do you know which requests are from your app and which are from someone trying to steal data?
If your API endpoints have no authentication, you have already been hacked. You just do not know it yet. Anyone can hit your endpoints and pull user data, create fake records, or delete everything.
You need to secure your API endpoints properly. Every endpoint that is not public needs to verify that the request comes from an authenticated user. Not just any user, the right user. If your endpoint returns user profile data, it needs to check that the user requesting the data owns that profile.
Token authentication is the standard. JWT vs session authentication is a choice but either is better than nothing. JWTs are stateless and scale well. Sessions are simpler and easier to revoke. Pick one and implement it consistently across all your endpoints.
But tokens alone are not enough. You need rate limiting. Without it, someone can brute force your authentication endpoints. They can try thousands of passwords until one works. Rate limiting stops that. It lets you sleep at night.
The authentication you probably rushed
You needed users to sign up. You asked AI to add authentication. It gave you something that works. But does it actually keep people out who should not get in?
Password storage is the first test. Open your database. Look at the passwords column. If you can read the passwords, you have already failed. Passwords must be hashed with a slow algorithm like bcrypt or Argon2. Not MD5. Not SHA1. Not plain text. If AI built your auth and you did not specify hashing, go check right now. I will wait.
Password reset flows are where most breaches happen. AI will generate a reset flow that emails a link with a token. But where does that token live? How long does it last? Can it be guessed? If your reset tokens are sequential numbers or timestamps, I can reset any user’s password just by trying enough combinations.
Session management matters too. When a user logs in, you give them a session or a token. How long does it last? Does it expire? Can a user be logged in from ten devices at once? Can you force logout from all devices if needed? These are not edge cases. These are security features your users expect.
SQL injection is still killing apps
You would think we solved this twenty years ago. We did. But AI keeps reintroducing it because AI does not know better.
Look at any place where your app takes user input and talks to the database. Search forms. Login forms. Comment boxes. Profile updates. If you are building SQL strings by concatenating user input, you are vulnerable to SQL injection.
Someone types '; DROP TABLE users; -- into your search box. Your app builds a query that looks like SELECT * FROM products WHERE name = ''; DROP TABLE users; --' and suddenly your users table is gone. This is not theoretical. This happens.
The fix is parameterized queries or an ORM that handles escaping for you. Never trust user input. Never build SQL strings by hand. If AI wrote raw SQL queries for you, go replace them with parameterized versions immediately.
The same applies to NoSQL databases. MongoDB injection is real. If you are building queries with user input, you are vulnerable. Use the driver’s built-in methods. Do not construct JSON queries from strings.
How to store user data securely
Your users trust you with their information. Names, email addresses, phone numbers, maybe physical addresses, maybe ID numbers. This data is valuable. People will try to steal it.
Encryption is your friend. Data in transit needs TLS. Your site should be HTTPS only. No exceptions. Modern hosting makes this easy. Use it.
Data at rest is more complicated. If someone gets into your database, can they read everything? If you store sensitive data like ID numbers or medical information, you should encrypt it. Not just hash it. Encrypt it with a key that is not in the database.
But encryption keys need to be stored somewhere safe. Not in the code. Not in the database. Environment variables are okay but better is a proper secrets manager. If you are small, environment variables are probably fine. Just make sure they are not in your GitHub repo.
Personal information has legal protection now. POPIA in South Africa means you can be fined for mishandling user data. You need to know what data you store, why you store it, and how long you keep it. If you do not need it, delete it. Less data means less liability.
The admin panel is the crown jewels
You probably have an admin area. Somewhere you can see all users, all orders, all data. This is the most dangerous page in your entire application.
If someone gets into your admin panel, the game is over. They can do anything. Delete everything. Steal everything. Send emails as you. The damage is unlimited.
Secure your admin panel like your business depends on it, because it does. Put it behind a VPN if possible. Use strong authentication with multi-factor authentication. Limit access by IP address. Log every action. Alert yourself when someone logs in.
And for the love of everything, do not have a default admin account with a default password. Change it. Make it long. Make it random. Store it in a password manager, not on a sticky note.
The security review you need
You are not a security expert. You did not mean to become one. You meant to build a business. But here you are, responsible for protecting your users’ data.
You need a web application security review from someone who knows where to look. Not because you are stupid, but because security is a full-time job and you already have one. You need someone to poke at your app and find the holes before the bad guys do.
A proper review looks at everything. Authentication flows. API security. Database access. Third-party integrations. Deployment configuration. Environment variables. File uploads. Error messages that leak information. Everywhere data moves, everywhere users interact.
They will find things. They always do. A missing rate limit here, a verbose error message there, a JWT that never expires. These are not signs that you failed. They are signs that you are human and you built something complex.
Custom app troubleshooting for security is different from debugging features. Security bugs do not crash your app. They sit quietly, waiting for someone to exploit them. You cannot find them by testing happy paths. You have to think like someone who wants to break in.
Production readiness includes security
You have been focused on making your app work. Features, performance, user experience. Security felt like something you could add later.
Later is now. Security is not a feature you bolt on at the end. It is baked into how you build. If you try to add it after the fact, you will miss things. You will have gaps. Attackers will find them.
Production readiness for a web application means it can survive in the wild. The wild is full of people trying to break in. Not because they hate you, but because your data is valuable and your security is their opportunity.
You need to test your security before you have users. Run automated scanners. Try to hack yourself. Better yet, pay someone to try to hack you. The cost of a security review is nothing compared to the cost of a breach.
When to call for help
You can fix some of this yourself. You can add rate limiting. You can check your password hashing. You can verify your payment webhooks. But there is a limit to what you can see in your own system.
You need someone who has broken into enough applications to know where you are vulnerable. Someone who can look at your code and see the SQL injection you missed, the broken access control you assumed worked, the exposed admin endpoint you forgot about.
A technical partner for an AI startup does not just write code. They look at your system and ask what happens when someone tries to break it. They help you build defenses before you need them.
I am that person. Twenty five years of building and breaking systems. I have seen every mistake founders make with security because I made most of them myself. I do not want to scare you. I want to help you build something that lasts.
Now what?
Your app has user data and payment information. That makes you a target. Not because you are big, but because you are small. Small targets are easy targets. Attackers know you cannot afford the same security as the big banks.
But you do not need bank-level security. You need basic competence. You need to close the obvious holes. You need to protect your users from the automated attacks that sweep the internet looking for easy prey.
AI helped you build fast. Now you need to build safe. The features that got you here will not protect you tomorrow. Security is not optional. It is the price of staying in business.
If you are lying awake wondering whether your app is secure, you already know the answer. It needs work. Let someone who has done this before look at it before someone else does.
