Prompts Guide v0 UI Generation

v0 Prompts: Write Better Prompts for Secure UI

Generate beautiful components that don't ship with security holes

Quick Answer

The best v0 prompts are specific about security, not just UI. v0 generates stunning components but often exposes secrets via NEXT_PUBLIC_ and skips server validation. Add security requirements to every prompt: "use Server Actions", "validate with Zod on server", "no NEXT_PUBLIC_ for API keys". Copy the templates below to get secure components from the start.

Why v0 prompts need security context

v0 excels at generating beautiful UI fast. It uses shadcn/ui components, handles responsive design, and creates production-ready React code. The problem: v0 optimizes for "works in the demo," not "secure in production."

According to Vercel's own blog, they've blocked over 17,000 deployments in a single month for exposed secrets. Most were NEXT_PUBLIC_ environment variables that v0 suggested. The fix isn't avoiding v0 - it's prompting it correctly.

Vibe coders who add security requirements to their prompts get the same beautiful UI with safer defaults. The templates below bake in the security patterns that v0 skips.

Copy-paste v0 prompt templates

These prompts have been tested to generate more secure code. Each includes explicit security requirements that prevent common v0 security patterns.

Forms

Secure Form with Server Action

Contact form with server-side validation and CSRF protection

Create a contact form component with:

UI:
- shadcn/ui form components (Input, Textarea, Button)
- Loading state on submit button
- Error messages below each field
- Success toast on completion
- Mobile-responsive layout

Security:
- Server Action for form submission (use server directive)
- Zod validation on server (not client-only)
- Rate limiting placeholder comment
- No console.log of user data
- Sanitize inputs before display

Fields: name, email, message
Include TypeScript types for form data.

Pages

Auth-Protected Dashboard

Dashboard with session check and protected data fetching

Create a dashboard page component with:

Auth:
- Check session at top of Server Component
- Redirect to /login if not authenticated
- Use auth() from your auth library pattern

Data:
- Fetch user data server-side only
- Never expose user IDs in client bundle
- Show loading skeleton while data loads

UI:
- Stats cards row (4 metrics)
- Recent activity list
- shadcn/ui components throughout
- Responsive grid layout

Security:
- No client-side data fetching for sensitive data
- Server Component by default
- Use session.user.id, not URL params for user lookup

Forms

Secure File Upload

File upload with type validation and size limits

Create a file upload component with:

Validation:
- Accept only images (jpg, png, webp)
- Max file size 5MB
- Validate MIME type on server, not just extension
- Reject files with suspicious names

Upload:
- Server Action for upload handling
- Show upload progress
- Preview uploaded image
- Delete/replace option

Security:
- Never trust client-side file type
- Generate random filename on server
- Store outside public directory
- Return signed URL for display

UI:
- Drag and drop zone
- shadcn/ui styling
- Error states for invalid files
- Mobile-friendly touch targets

Components

Data Table with Pagination

Server-side paginated table with search

Create a data table component with:

Data Handling:
- Server-side pagination (not client filtering)
- URL-based page state (searchParams)
- Server Component data fetching
- Never send full dataset to client

Features:
- Search with debounced input
- Sortable columns (server-side)
- Page size selector (10, 20, 50)
- Loading states between pages

Security:
- Validate page/limit params on server
- Sanitize search input before query
- Limit maximum page size to 100
- No SQL injection in sort column

UI:
- shadcn/ui Table components
- Pagination controls
- Empty state
- Responsive with horizontal scroll on mobile

Integration

Environment-Safe API Integration

Third-party API call with proper secret handling

Create a component that fetches data from an external API:

API Setup:
- API key in server-side env var (NOT NEXT_PUBLIC_)
- Fetch in Server Component or Route Handler
- Never expose API key to client bundle

Error Handling:
- Handle API rate limits gracefully
- Show user-friendly error messages
- Log errors server-side only (no stack traces to client)
- Retry logic with exponential backoff

Caching:
- Use Next.js fetch caching appropriately
- Revalidate on reasonable interval
- Show stale data while revalidating

UI:
- Loading skeleton matching data shape
- Error state with retry button
- shadcn/ui card for data display

Security add-ons for any v0 prompt

Add these lines to any v0 prompt to prevent specific vulnerabilities. Each addresses a common pattern in v0-generated code.

NEXT_PUBLIC_ Exposure

Use server-side environment variables only. Never prefix sensitive keys with NEXT_PUBLIC_.

Why: v0 defaults to client-accessible env vars for quick demos

Missing Server Validation

Validate all inputs on the server with Zod. Client validation is for UX only, not security.

Why: v0 often generates client-side validation only

Unprotected Server Actions

Check authentication at the start of every Server Action before processing.

Why: v0 generates Server Actions without auth checks

Client Data Fetching

Fetch sensitive data in Server Components only. Use useEffect for non-sensitive data only.

Why: v0 defaults to client-side fetch patterns

Debug Logging

Remove all console.log statements. Never log user data or errors with stack traces.

Why: v0 includes debug logs that may expose data in production

Prompt patterns that work

The difference between a vague prompt and a specific one is often the difference between vulnerable code and secure code.

Be Specific About Stack

Vague prompt Create a login form

Secure prompt Create a login form using shadcn/ui, react-hook-form, and Zod validation with Server Action submission

Vague prompts get generic, often insecure output

Request Security Explicitly

Vague prompt Add authentication

Secure prompt Check auth() session at component top, redirect to /login if null, never trust client-side auth state

v0 won't add security unless you ask

Specify Server vs Client

Vague prompt Fetch user data

Secure prompt Fetch user data in Server Component using session.user.id, never expose userId in client bundle

v0 defaults to client patterns that expose data

Include Error States

Vague prompt Add form validation

Secure prompt Add Zod validation with field-level errors, form-level error banner, and loading state on submit

Complete specs get complete implementations

After v0: what to check

Even with good prompts, review v0 output before shipping. This checklist catches what prompts miss.

Search for NEXT_PUBLIC_

Any NEXT_PUBLIC_ variable with "KEY", "SECRET", or "TOKEN" is exposed to browsers. Move to server-only env vars.

Verify "use server" directive

Server Actions need "use server" at the top. v0 sometimes forgets it, making your "server" code run on client.

Check auth in Server Actions

Every Server Action should check auth() before doing anything. No auth check = anyone can call it.

Find client-side fetches

useEffect + fetch for user data is usually wrong. Sensitive data should come from Server Components.

Remove console.log

v0 adds debug logs. In production, these may expose user data or error details to attackers.

Frequently asked questions

What are the best prompts for v0?

The best v0 prompts are specific about component structure, include security requirements, and reference shadcn/ui patterns. Start with "Create a [component] using shadcn/ui with [specific features]". Add security context like "with server-side validation" to avoid common vulnerabilities in generated code.

How do I write good v0 prompts?

Be specific about what you want: component type, styling framework, data handling, and security requirements. Include constraints like "use Server Actions" or "validate with Zod". Reference existing components with @-mentions. Avoid vague prompts like "make a login page" - instead specify auth provider, validation, and error handling.

Can v0 generate secure code?

v0 can generate more secure code with the right prompts. Explicitly request server-side validation, environment variables for secrets, and auth checks. However, always review generated code - v0 optimizes for working UI, not hardened security. Common issues include NEXT_PUBLIC_ secret exposure and missing server validation.

What should I include in v0 prompts?

Include: component purpose, UI framework (shadcn/ui, Tailwind), data requirements, security needs (validation, auth), error states, loading states, and mobile responsiveness. The more specific your prompt, the better the output. Security requirements are especially important since v0 defaults to client-side patterns.

How do I get v0 to use Server Actions?

Explicitly request Server Actions in your prompt: "Create a form that submits via Server Action with Zod validation". v0 often defaults to client-side fetch. Specify "use server directive" and "validate on server" to get server-first patterns. Review generated code to ensure the "use server" directive is present.

Why does v0 expose my API keys?

v0 often uses NEXT_PUBLIC_ prefix for environment variables to make code work in client components quickly. This exposes secrets to the browser. Always specify in prompts: "use server-side environment variables, not NEXT_PUBLIC_". Review generated code for any NEXT_PUBLIC_ variables containing sensitive keys.

Can I use v0 prompts in other AI tools?

v0 prompts are optimized for v0.dev but work in other tools with modifications. v0-specific features like shadcn/ui component references and Vercel deployment context may need adjustment. The security-focused parts of prompts (validation, auth patterns) translate well to Cursor, Claude Code, and Bolt.

Related guides

Scan your v0 project

Catch NEXT_PUBLIC_ exposure, missing auth, and other v0 patterns before deployment.

Scan Your Code Free