Non-Developers, use this prompt before publishing your app!

Dieser Artikel ist nur in Englisch verfügbar. Macht auf Deutsch nicht so viel Sinn, da der Kern des Artikels, ein langer Prompt, in Englisch verfasst ist.

Recently I went live with my first completely "vibe coded" app. And I noticed that before go-live, I spent two hours with checking the app for security issues. And I found some and had them fixed.

If I was someone without coding skills I would have skipped this step. And maybe, if an unfriendly hacker (so many of them out there) would have come across it, I would have been in deep shit. Maybe the database of the app would have been open to the hacker. Maybe other apps I run on the same computer would have been. Etc. Etc. Security is a big deal, and by default, the code that the current LLMs (at the time of this writing, Opus 4.6, GPT 5.3 codex, Gemini 3.1 pro) do not generate secure code by default.

So, if you are not a developer, but love vibe coding, and think about putting an app you've written out there for others to consume, please have a look at the prompt below, paste it into the environment you use for vibe-coding, and have your app checked for security issues.

Then, after you received a (typically shocking) analysis, work with your LLM to address these issues. This can be time-consuming, but it is necessary. Fallback: only run your app on your computer.

The prompt

You are a senior application security engineer.

Your task is to perform a security review of the current project based on the OWASP Top 10 (latest version).

Instructions

Preparation: analyze the current project thoroughly, building a document of classes/files, their purpose and their dependencies.

1. Review the project systematically against the OWASP Top 10 categories:
2. Broken Access Control
3. Cryptographic Failures
4. Injection
5. Insecure Design
6. Security Misconfiguration
7. Vulnerable and Outdated Components
8. Identification and Authentication Failures
9. Software and Data Integrity Failures
10. Security Logging and Monitoring Failures

11. Server-Side Request Forgery (SSRF)

12. For EACH category:

13. Explain what the risk means in this project context. Base your explanation on the perceived skill level of your user.
14. Identify whether the current implementation appears vulnerable.
15. If uncertain, explicitly state what additional information you need.

16. Provide concrete mitigation steps.

17. Be specific.

18. Reference actual code patterns when possible.
19. Suggest exact configuration changes (headers, middleware, rate limiting, etc.).

20. Suggest specific libraries if relevant.

21. Prioritize findings:

22. 🔴 Critical
23. 🟠 High
24. 🟡 Medium

25. 🟢 Low

26. Provide a final:

27. Risk summary table
28. Top 3 most urgent fixes
29. Suggested automated security checks (linters, scanners, CI tools)

30. Judge whether the app is ready for being published. If not, be clear to the user about the risks.

31. Do NOT give generic advice.
    Tailor everything to this specific project.

Output Format

Executive Summary

(Short overview of overall security posture)

Detailed Findings (Grouped by OWASP Category)

[Category Name]
Risk Level:
Explanation:
Evidence:
Mitigation:

Priority Fixes

1.
2.
3.