Український розробник Павло Снєда зібрав топ-п’ять помилок у безпеці, які, за його спостереженнями, регулярно трапляються в коді новачків, написаному за допомогою ШІ.
Ukrainian developer Pavlo Snieda has compiled the top five security mistakes that, according to his observations, regularly occur in novice code written using AI.
The developer spoke about this on LinkedIn, based on his experience in testing live code projects written in NestJS.
«Everyone is coding with AI these days, I’m not an AI hater, but when I review such code, security is almost non-existent,» the developer wrote. Here are the most common mistakes he sees.
The program must check what data it is allowed to receive from the user. If the validation of the entered data is configured incorrectly, the server may accept from the user not only the allowed information, but also unnecessary data. For example, the system may have standard properties: user: name, password, e-mail, as well as the value isAdmin. So when the validation is insecure, the user can change this value to isAdmin=true, and the system can skip it and elevate his rights to the administrator.
The system verifies that a person is logged in to their account, but may not check whether they have permission to see specific data. For example, if the order number can be changed in the address bar or query, the user can replace it with someone else’s order number. If the server does not check who it belongs to, it may show someone else’s data.
A developer can lock most pages or features but forget about one. Sneda recommends locking everything by default and only individually unlocking what really needs to be public.
For example, the application needs to show the user’s name, avatar, and registration date, but along with them, the server sends the entire record from the database. It may contain service or sensitive data — password hashes, tokens, or other information that the user should not see. Therefore, it is worth transmitting only those fields that are really needed.
Snieda also points out the basic security settings before launching a product. For example, if the number of login attempts is not limited, the password can be tried without restrictions, which makes it easier to hack accounts. And overly detailed error messages can reveal table names and other internal system details to an outsider.
In the comments, the developers also suggested several ways to secure the AI code. For example, Olena Kuznetsova advises running the result through LLM with a request for a security review. Oleksiy Vykhrystyuk suggests using low-code platforms for vibcoding, citing Oracle APEX and APEXlang as examples. And Andriy Zilnyk suggested adding to the rules for the AI assistant OWASP Top 10 — a list of the most critical risks for web applications.
Another commenter, Nazariy Muska, pointed out that .env files, where developers often store passwords, tokens, and API keys, could expose this data to third parties if accidentally uploaded to an open repository.
Previously, dev.ua wrote about a study that tested the security of thousands of applications created using vibecoding, which found that about 40% of the studied applications disclosed confidential data. In particular, medical and financial information, as well as customer contacts and the history of their conversations with chatbots.
