Security, checklist and errors
Secrets: keys cannot be stored in the frontend
If the key ended up in the JS code that went to the browser, consider the key to be compromised. Lovable directly writes “do not store secrets in frontend code” and directs them to be stored in Secrets/Edge Functions.
Basic practices OWASP on secrets management: centralized storage, access control, rotation, audit.
Practical minimum for MVP:
- Keys - only in server-side (edge functions / backend / secret store).
- Access to secrets—limit.
- Logs should not print secrets.
BOLA: the main hole in the “MVP with tables”
BOLA (Broken Object Level Authorization) - when you have an endpoint like /items/{id}, and the system checks “you are logged in”, but does not check that this object belongs to you. Then the attacker changes the id and receives someone else’s data. OWASP puts this first.
Mini-rule: any endpoint that accepts an object id must check permission at the object level.
Input data validation: “keep the garbage out”
OWASP states the goal of input validation simply: to let only well-formed data in as early as possible so as not to break the system or open up attacks.
Practice for MVP:
- Input validation (schema validation).
- Whitelist approach (allowed values), where possible.
- Limiting the size of requests (so as not to consume resources).
Webhooks: check the signature
If you are taking webhook and you don’t check the signature - anyone can knock on your endpoint like “GitHub/payment/whatever.” GitHub provides official validation guidance and recommends X-Hub-Signature-256 (HMAC-SHA256).
Env vars: useful, but do it right
V Vercel env vars is a key-value pair outside the source, and changes apply only to new deployments (redeploy is needed). There is a “Sensitive environment variables” mode - the values become unreadable after creation.
Hallucination model
Models can generate confident text/code that looks correct but is actually incorrect - this is called hallucination. This is one of the main reliability barriers LLM and requires verification and restrictions.
Tokens and cost
Tokens is a “volume counter” from which the cost increases. If you run an agent through endless iterations without a clear “done,” you pay for chaos.
The main mistakes of beginners
- Asking to “do everything at once” —the result will be chaotic.
- Do not check —AI can make mistakes, and without checking you won’t notice it.
- Do not control secrets — leaked key = potential money and security.
- Roll out the prototype into production —and be surprised by quality problems.
Checklist before publication
- Secrets: no keys in frontend/repository
- Authorization of objects: all endpoints with :id check owner/permissions (BOLA closed)
- Validation: input data is checked, there are size limits
- Webhooks: signatures are validated, there is protection against repetitions (idempotency key)
- Environments: dev/preview/prod separated; preview-deploy works
- Git-story: there is a repository, you can roll back; there are checkpoints for agent edits
- README: anyone can run the project according to the instructions
- Logs/errors: no leaks of personal data and secrets