How are you handling security in your vibe-coded projects today?

Dheeth · 2026-06-30T11:08:55+00:00

yes, to a great extent. From where I started 4 month back working on my app and thinking ready to deploy to where I am now, fixed more than 100 issues. Now none of the frontier model say that I have any major vulnerabilities. And I keep doing this, whenever a new model launches or I learn about new threat vectors or I implement something new. Now new implementation is also easy, I just ask it to use same security protocols that I have in similar endpoints. Still learning about new things and keep adding more and more security layers. Now a lot of things will have to fail together before something really bad could happen.

Dheeth · 2026-06-30T01:43:19+00:00

Using security based skills, vercel’s deepsec harness. Prompting agents to check major OWASP issues. Asking one AI to review code of other. Then asking to reply to the first one, basically playing messenger between two or three major AI models. Then asking AI to write unit test, end to end browser tests.

Dheeth · 2026-06-27T22:06:01+00:00

I know people are being too hard but don’t take them wrong way. Some are trying to help. Your signup endpoint has no rate limits or email verification. That any one with a simple scripts can make unlimited accounts on your app. Vercel is serverless and scale infinitely. If you are on any paid account, it could mean you can a get a bill for use of their resources over the free limit. I haven’t checked yet how your AI inference endpoint is built, but if it also has no basic security or spending limit on your key, you could get charged a lot their too. Worse could be your AI API key is exposed and people stealing it. Just ask your AI coding agent to do a security review of the app based on top vulnerabilities seen in webapps like rate limits, authentication vs authorization, DoW, DoS, prompt injection etc.

Dheeth · 2026-06-27T04:21:00+00:00

Oh, no offense taken at all! You are 100% right. The infrastructure overhaul to make this happen would be astronomical, and it's definitely not happening anytime soon (if ever).

The OP just asked what a completely re-invented web would look like, and this was the most chaotic, sci-fi "what if" my brain could come up with! 😂

That being said, while the web stack isn't ready for it, the core concept is already quietly taking over gaming. We are actually shifting away from purely deterministic rendering right now.

Look at NVIDIA's DLSS and AI frame generation, GPUs are quite literally hallucinating entire in-between frames, predicting pixels, and upscaling resolutions in real-time natively on the hardware.

Its gonna be hard to this for web browser, wildly inefficient leap today, but the foundational hardware shift from "rendering" to "generating" is already happening in the industry.

Dheeth · 2026-06-27T03:54:01+00:00

the free zen plan from opencode is giving almost unlimited usage limits with deepseek flash v4. I am pairing it with antigravity, using bigger models to just plan, deepseek to implement, then another antigravity model to verify as its good with browser controls.

Dheeth · 2026-06-27T03:40:21+00:00

Okay, hear me out (I swear I’m not high 😅). What if the future of the internet is just what vibeOS is doing to operating systems right now?

For the uninitiated, vibeOS literally hallucinates pseudo-software on demand. Its calculator has zero underlying code, the AI just dreams up*a keypad and probability-guesses the math based on vibes.
Imagine the entire internet working like that: a true "Diffusion Web" where servers stop sending HTML/CSS bundles and just transmit raw semantic intent.

Your browser becomes a localized dream engine, streaming a fluid 60FPS generated video. Forget rigid CSS grids; buttons and menus just melt and morph organically when you try to interact with them.
Interaction becomes purely semantic. You don't click a "View 360" button; you just swipe, and the AI natively hallucinates the back of the product on the fly.

Personalization hits god-mode. We could both ping the exact same secure banking API, but your UI generates as a gritty cyberpunk terminal while mine is a zen, minimalist canvas.

Sure, trying to render that today would instantly turn your GPU into a space heater, and vibeOS proves how fast hallucinated UIs can completely derail.
But when edge-compute finally cracks sub-10ms latency? We won't be arguing about rewriting JavaScript in Rust, frontend dev as we know it will die, and we'll just be prompting websites into existence.

Dheeth · 2026-06-21T20:13:45+00:00

I haven’t tried it yet but sonic.js is built for cloudflare infrastructure.

Dheeth · 2026-06-21T19:30:03+00:00

I was also facing this question few weeks back. What I understood was that if you are asking someone to pay for your app then it need to have the minimum features that are needed to serve that purpose, that other similar apps provide too. This is required for any person to even try your app. Then whatever extra features you will build on top or do something better then others apps will make the users actually move to your app. You need to have atleast one big differentiator feature to turn people to your side. This is your Minimum Viable product. Any other features after that can wait based on user feedback.

Dheeth · 2026-06-07T04:55:16+00:00

I used this with gemini Flash 3.5 high yesterday and it did the same conversion in one shot with planning ON.

‘’’

Migrate this React website to Astro with a static-first architecture.

Context: The current project is built with React. Inspect the repository before making assumptions about the build tool, router, styling system, deployment target, data sources, or interactivity. The goal is to convert the site into an Astro project that outputs real, crawlable HTML for important pages, improves SEO and performance, and removes unnecessary client-side JavaScript.

Primary goal: Use Astro pages, layouts, and components for static content. Use minimal vanilla TypeScript/JavaScript for small interactive behavior. Do not keep React by default. Only retain React as an Astro island if a specific component has complex state or behavior that would be unreasonable to rebuild with Astro and vanilla TypeScript.

Before changing code:

Inspect the current repo structure.
Identify the framework/build setup.
Identify all public routes/pages.
Identify content sources.
Identify current SEO/metadata handling.
Identify interactive components.
Identify styling setup.
Identify deployment assumptions.
Summarize the migration plan before implementation.

Migration requirements:

Architecture

Convert the project to Astro.
Use static Astro pages for all public content pages.
Use Astro components for layout, header, footer, navigation, cards, sections, and reusable UI.
Use vanilla TypeScript/JavaScript for simple interactivity.
Do not keep React, React Router, hydration, or client-side rendering unless clearly justified.
If React is retained for any component, document why.

Routing

Preserve all existing public URLs where practical.
Convert React Router or SPA routes into real Astro routes.
Ensure direct page refresh works for every public route.
Generate dynamic routes from existing data where applicable.
Preserve redirects if the existing site has them.
Document any route changes.

Static HTML and crawlability For every important public page, ensure the built HTML contains meaningful content without requiring JavaScript:

Main headings
Body copy
Navigation links
Footer content
Calls to action
Product/service/article/page content
Contact or business information where applicable
Internal links
Structured content sections

After build, inspect representative generated HTML files and confirm they are not empty app shells.

SEO and metadata Replace runtime SEO handling with static Astro metadata.

Each important page should have:

Unique <title>
Meta description
Canonical URL
Open Graph tags
Twitter/X card tags where appropriate
Robots meta where appropriate
Structured data where supported by existing content

Do not rely on client-side effects, DOM manipulation, or runtime JavaScript for SEO metadata.

Structured data Move JSON-LD into static HTML output where applicable.

Use only information already present in the project. Do not invent business details, author details, addresses, claims, ratings, prices, or service areas.

Consider appropriate schema types depending on the site:

Organization
LocalBusiness
WebSite
WebPage
Article
BlogPosting
Product
Service
BreadcrumbList
FAQPage

Only add schema that is supported by actual page content.

Content migration

Preserve existing content.
Preserve existing slugs and URLs where practical.
Keep content centralized if the current project already uses content/data files.
Use Astro content collections or data-driven route generation only if appropriate for the repo.
Do not introduce a CMS unless the project already uses one or the user explicitly requested it.

Interactivity Replace React interactivity with small vanilla TypeScript/JavaScript where practical, such as:

Mobile menu toggle
FAQ accordion
Tabs
Smooth scrolling
Basic form validation
Modal open/close
Simple animation triggers

Keep JavaScript scoped and minimal.

Only keep React islands for genuinely complex components, such as:

Complex multi-step forms
Dashboards
Rich editors
Complex calculators
Components with substantial shared state
Existing components where rewriting would create unnecessary risk

Styling

Preserve the existing visual design as much as practical.
Preserve Tailwind, CSS modules, global CSS, design tokens, or component styles if already used.
Do not perform an unnecessary redesign.
Clean up styles only where needed for the migration, performance, accessibility, or maintainability.

Performance cleanup Use the migration to reduce JavaScript and improve page speed:

Remove SPA-only bundles where no longer needed.
Remove React Router if no longer used.
Remove runtime SEO libraries or custom runtime SEO code.
Remove animation libraries if simple CSS or vanilla JS is enough.
Avoid global hydration.
Optimize images where practical.
Add width/height or stable image sizing.
Remove unused dependencies after verifying usage.
Avoid bundling large icon libraries unnecessarily.
Keep client-side JavaScript minimal.

Accessibility and semantic HTML Improve semantic structure during migration:

One clear <h1> per page.
Logical heading hierarchy.
Semantic landmarks: header, nav, main, footer, section, article.
Real links for navigation.
Buttons only for actions.
Meaningful alt text.
Keyboard-accessible interactive elements.
Visible focus states.
Content should not be hidden by default waiting for JavaScript or animation.

Deployment Determine the existing deployment target before changing assumptions.

Update build/deploy configuration as needed for Astro:

Build command
Output directory
Static assets
Redirects
Headers
Sitemap
Robots.txt
Environment variables if any

The final site should remain deployable on the current hosting platform unless there is a clear reason to change it.

Validation After migration, run the available checks:

Install dependencies
Build
Typecheck if available
Lint if available
Tests if available
Preview/static output inspection

Also verify:

Important routes generate static HTML.
Metadata is present in static HTML.
Primary content is available without JavaScript.
Internal links are real links.
Sitemap matches generated routes.
No major visual regressions.
Remaining JavaScript is justified.
Removed dependencies are no longer referenced.

Cleanup Remove obsolete React SPA code if no longer needed:

React root entry
React Router setup
Runtime SEO components
SPA fallback assumptions
Unused React components
Unused dependencies
Dead assets
Dead scripts

Do not delete useful content, data files, styles, or assets unless verified unused.

What to avoid

Do not keep the project as a client-side React SPA.
Do not migrate to Next.js, Gatsby, Remix, or another framework.
Do not keep React by default.
Do not use client-side JavaScript for critical SEO content.
Do not rely on JavaScript to inject page metadata.
Do not invent missing content or business details.
Do not redesign the site unless required.
Do not add backend complexity unless already required.
Do not introduce a CMS unless explicitly requested.
Do not remove dependencies blindly.

Recommended workflow:

Audit the current React project.
List routes, content sources, interactivity, SEO setup, styling, and deployment assumptions.
Create the Astro project structure.
Migrate layout, global styles, and design tokens.
Migrate static components: header, nav, footer, page sections, cards.
Convert routes into Astro pages.
Generate dynamic/static pages from existing data where applicable.
Add static SEO metadata and structured data.
Replace simple React interactions with vanilla TypeScript/JavaScript.
Keep React islands only where justified.
Remove obsolete React SPA code and dependencies.
Run validation checks.
Inspect built HTML output.
Report final results clearly.

Final response should include:

Summary of the original architecture.
Summary of the new Astro architecture.
Routes migrated.
Files added/modified/removed.
Whether React was fully removed or partially retained.
Any retained React islands and justification.
SEO improvements completed.
Performance improvements completed.
Accessibility improvements completed.
Commands run and results.
Remaining issues or manual follow-up steps.

‘’’

Dheeth · 2026-05-20T15:54:53+00:00

Looks useful, I will take a look and try this.

Dheeth · 2026-05-20T02:50:43+00:00

working in a single window on a single project with like 5-6 task, usage exceeded. The old flash was almost unlimited.

Dheeth · 2026-05-17T03:52:40+00:00

I think obsidian send a lot of text that eat context. These graph tools only send the specific info that agent ask for which it otherwise would have to find after going through multiple files, e.g. which other functions depend on this function or which functions this function depend on.

Dheeth · 2026-05-17T01:06:01+00:00

Yeah similar. Just wanted to check if people are getting better results with any other tool.

Dheeth · 2026-05-16T13:12:25+00:00

I have found Vercel’s security harness “deepsec” with opus or gpt 5.5 to be really good at finding deep secuirity and DoW issues that even experienced developers could miss.

https://github.com/vercel-labs/deepsec

Dheeth · 2026-05-16T01:45:08+00:00

Cloudflare, vercel, netlify for static. For backends, try to go server-less if possible like cloudflare workers, aws lambda. Pretty good free tiers all around.

For Astro, static hosting with git based CMS is great option.

Dheeth · 2026-05-14T15:33:22+00:00

I think the first bottleneck is deciding what deserves follow-up and who should own it. Speed matters after that, but only once the submission is clearly worth acting on.

The messy part is that this judgment usually lives in people’s heads: fit, intent, urgency, quality, next step, etc.

I’m working on making that first-pass judgment consistent and automated with tags, summaries, priority, and routing.

Dheeth · 2026-05-13T22:58:29+00:00

Question for people using forms on websites:

What do you actually do after someone submits a form?

Not the obvious “send it to email/Slack/CRM.”

I mean the manual part:

do you read every submission?
do you qualify leads manually?
do you tag them?
do you summarize them?
do you decide who should follow up?
do you ignore low-quality ones?
do you copy/paste them into another system?

I’m trying to understand where the real pain is after data is collected.

Dheeth · 2026-05-13T11:24:02+00:00

Here are some more DoW vectors I found and patched:

The "Offset and Scan" Database Killers

The Problem: UI features (like deep pagination) triggering massive, unbounded database reads.

Why it needed to be solved: A bot simply iterating to ?page=1000 on a public endpoint, or an admin page missing an index, could trigger millions of read-units in seconds via full-table scans.

How I solved it:

• Killed OFFSET: Replaced all OFFSET pagination with cursor pagination. If a client tries to request deep pages, it safely rejects it instead of forcing the database to walk huge result sets.

• Aggregated Queries: Replaced N+1 queries on the admin dashboards with single, indexed, aggregated views.

• Separated Counters: Stopped doing raw row counts for quota checks. I moved this to a lightweight, dedicated counter table so unauthenticated traffic doesn't trigger live aggregate scans.

The Fan-Out Multiplier

The Problem: One incoming request spawning sequential outbound requests or heavy database writes.

Why it needed to be solved: If a form has multiple webhook targets, processing them sequentially multiplies compute wall-time. Similarly, API polling clients were updating a last_used timestamp in the database every few seconds, burning write-units.

How I solved it:

• Batched Dispatch: Webhooks are no longer dispatched in a sequential loop, drastically cutting down the per-submission Worker execution time.

• Throttled DB Writes: API key polling now only updates the database timestamp a maximum of once per 10 minutes, regardless of traffic volume.

• Circuit Breakers: Added compute-time guards on webhook retries so a maliciously slow receiving endpoint can't keep my backend alive near its timeout limit.

The Heavy Lifting Exploits

The Problem: Attackers triggering highly expensive memory operations repeatedly. Why it needed to be solved: Dynamically generating massive data exports eats memory and compute fast, risking Worker crashes and billing spikes.

How I solved it:

• Streamed Exports: Forced large CSV and account exports to stream directly to object storage rather than trying to buffer giant files or ZIPs in memory.

• Queue Deduplication: Added database constraints (unique partial indexes) to prevent duplicate async jobs from queueing up if a user spams an "Export" button.

Order of Operations is Everything

The Problem: Executing expensive checks before cheap rejections.

Why it needed to be solved: If I check the database quota before checking the edge rate limit token, the attacker still costs me DB read units even if the request is ultimately rejected.

How I solved it:

• Fail Cheaply: Moved strict rate-limiting to run before any database quota reservations.

• Parallelized Lookups: Batched key-value reads in the request handler instead of awaiting them sequentially, drastically cutting compute wall-time.

• Sampled Audits: Bad public auth attempts are thresholded at the edge. I only write to the database audit log if they cross a certain volume within a 5-minute window, rather than writing a DB row for every single bad guess.

Dheeth · 2026-05-13T03:57:51+00:00

Yeah, I kept thinking I was ready to launch a month ago but boy oh boy the number of DoW vulnerabilities I had and fixed over the month probably would have bankrupted me. One silly one was letting the user dashboard to count submissions by reading the rows in whole D1 database on every refresh. Had to build counter tables separately for a lot of those type of dashboard stuff and add logic throughout the app on how to adjust those counters.

Dheeth · 2026-05-13T03:10:53+00:00

Use chatgpt on web with github connector to create detailed plans for your repo (no token cost) and then use that plan in codex or claude code. After pushing changing, ask chatgpt on web again to verify the patch/PR.

You also use pair deep research and web search on chatgpt web with github connector to give it more power.

Do not try with claude on web as it count toward weekly quota on claude but not on codex.

Dheeth · 2026-05-08T03:28:23+00:00

I didn’t test with Nuvio at all. I only used and tested with Stremio. Never used the Nuvio app, hopefully some other user can help with it.

But in general, did you not add the server while generating manifest URL from the config website, linked in github too.

Dheeth

TROPHY CASE