You're reading for free via Michael J. Fordham's Friend Link. Become a member to access the best of Medium.
Member-only story
Five things vibe coders should know (from a software engineer)
Tips to keep you and your users safe with actionable security improvements.
A few days ago I saw this tweet:
Followed by this one:
And it underlines a bit of a problem with vibe coding; people are unaware that the code they’re generating and the apps they’re deploying might be leaving them open to vulnerabilities.
That’s a problem not only they need to resolve fast, but the tools that facilitate their work, too.
Insecure code should not be generated, and if it is, the user should be warned about it prior to going live.
While some have been quick to point out that ‘vibe coders’ are bringing this upon themselves for not being real ‘devs’, personally I think it’s nice that so many people who have been unable to build products before (designers, product managers etc.) now have some of the tools to be in the driving seat.
So with that in mind, here are five key things that vibe coders should be aware of while developing their apps to keep themselves and their users safe.
1. Use an environment file for API keys
API keys are like your password, they should be kept secret and very secure.
When developing a production app, a software engineer should never include their API key in the code they push to GitHub or publish online, as it’d mean people can somewhat easily find it and use it themselves.
This means that they can effectively pretend to be you. They could rock up a huge bill in the third-party tools you’re using without you quickly realising. They could steal a list of all your customers’ information. Pretty dangerous territory.
An environment file helps with that, as it remains local on your device or hidden and secure in the deployment app of your choice (e.g. AWS), so you can still reference it in your code, but as long as you omit it from version control tools, it’s never committed to your repository and no-one else can see it.
Cloud providers like AWS usually have their own ways (e.g. Secrets Manager) to manage secrets in production.
I was surprised to find that not all AI dev tools currently support environment files, so you should check if yours does before beginning your product’s development.
2. Set limits on third-party tool accounts for spending
While you’re vibe coding and testing out different features, you may be using other third-party tools (like OpenAI etc.) for their functionality.
If you publish your product or are building in public, this means that others could be using your app way more than you anticipated, incurring you a huge API bill at the end of the month.
Additionally, if your app is now hosted on a platform like AWS, experimenting with different hosting features can lead to unexpectedly high bills.
My recommendation is that you set hard limits on the amount of money that can be spent in each third-party tool.
Most cloud providers and APIs (AWS, OpenAI, Google Cloud) have dashboards allowing you to set hard usage or spending limits. Always double-check these settings before deploying your app publicly.
You can then get a warning if you get close to your limit, and block the API call if you reach your limit.
3. Store user information securely
When software engineers are in school, one of the first things they tend to build is a simple authentication app.
They’ll store an email/username and a password in a database and then build a simple log in/sign up screen to test it works.
One of the key learnings from this task is that everything you did is likely very insecure. Most people skip encryption steps and hashing and just keep user details in plaintext. This is a really bad idea, because if someone gets access to your database (e.g. if you published your database connection info in your repository) they can now connect to it and steal everybody’s login information.
This not only makes your app insecure, but other apps too. People tend to re-use passwords, so if they’re caught out in one leak, they’ll likely have other accounts hacked too.
So, what should you do?
Ideally, use a third-party tool like Auth0 for authentication. These tools will manage user data and security much better than you can likely afford to, and so it’ll save you a headache going forward.
If you can’t use a tool like that, ensure you do two things:
- Encrypt all user data (with an initialisation vector to randomise things)
- Hash all user passwords/keys
You may now be thinking “why do we encrypt some things but hash others?”
The simple answer is encryption can be reversed while hashing can’t. So you want to encrypt information you may need to know or use in the future (e.g. a person’s name or email address) but hash something you’d never want anyone else to know (e.g. their password).
If going down the manual user info route, you should hash user passwords with a strong hashing algorithm, which automatically handles salting, which adds random data to passwords before hashing, preventing attackers from using precomputed tables to guess passwords.
4. Sanitise user inputs
Depending on the tool you’re using and how it interacts with your database, you may be susceptible to attacks like SQL injection or XSS.
Essentially this means users can input some nasty code which hijacks your database or app and makes it do things you never would’ve intended, like deleting your users table or showing pop-ups inside your application.
By sanitising your inputs, you can ensure input is formatted in such a way that it cannot do anything malicious.
Libraries like DOMPurify (for XSS in JavaScript) or parameterised queries/prepared statements (for SQL injection prevention) are useful in this scenario.
5. Rate limit your resources
Rate limiting is a security and performance strategy that restricts the number of requests a user can make to your APIs within a given time frame. It acts as a safety net, ensuring that your server resources remain available, stable, and protected from excessive or malicious traffic.
Without rate limiting, your service might be vulnerable to DDoS, brute-force or resource exhaustion attacks, which can severely impact your app’s performance and incur some nasty costs and potentially data loss.
Some tools that help with this are Cloudflare and Amazon’s AWS API Gateway. There are also tools available at the code-level if you can’t use either of these platforms.
If you follow these tips, your product will likely be much safer and nicer to use, while also not surprising you with unexpected bills, attacks and downtime.
Useful links for further reading:
Have fun building new things.
