The Dark Side of AI: Developing unsecure applications in minutes

Chris Lindsey, a field CTO with a background in healthcare software and security program leadership, opens by explaining why AI-assisted development matters and how quickly developers have adopted it. He walks through common prompting patterns, such as asking for a basic .NET Core CRUD application with Entity Framework and SQL Server, and argues that more specific prompts and breaking work into smaller steps produce better output.

The live build covers a backend and a React frontend generated mainly with Claude, with ChatGPT and Copilot also tried. Each model produced code that looked plausible, and when asked to secure it, the assistant added authentication, JWT handling, validation and rate limiting. The review then exposed gaps: a database connection string kept in configuration rather than a secrets manager, a password policy that differed between frontend and backend, an outdated serialization library with known risk, a CDN script loaded without a correct integrity hash, and encoding applied in the wrong layer. Compared with enterprise scanners, the assistants missed issues such as path traversal, log injection and regular expression denial of service.

The takeaways are to treat AI output as a draft from a developer without security training, to review diffs and run scanners before anything reaches production, to keep guardrails and coding standards in files the model can reference, to avoid pulling external dependencies live, and to rely on parameterized queries rather than generated sanitization.