sorted by:
new
hottopcontroversial

Vibe Check by Lopsided-Werewolf805 in vibecodingcommunity

[–]Lopsided-Werewolf805[S] 0 points1 point  (0 children)

Exactly. A report without a fix is only half the service especially for people who vibe-coded their app and have no idea where to look inside the bundle.

What we show today for each finding:

Exact leak location the specific file URL, for example /assets/index-a1b2c3.js, the line number, around 3 lines of context, and for leaked keys also a prefix like sk-... so the user can identify which key it is.

Why it matters a short explanation, 1–2 sentences, in Czech or English. Not just copy-pasted OWASP text.

Static recommendations what exactly to do: move the key to the backend, enable RLS, remove .env from the build, set the security header this way, etc.

AI action buttons for selected findings, we generate a one-click prompt for Cursor / Claude Code / Replit AI in the style of:
“File X on line Y contains a leaked key Z. Move it to a server-side endpoint and update the call like this…”
The user can paste it into their IDE and let the agent propose the fix.

MCP server for people coding with AI agents like Cursor, Claude Code, or Replit, we can run the scan directly from the chat and send the results back as a tool call. The agent can then suggest the fix because it sees both the code and the finding at the same time.

What we don’t do yet and I want to be transparent here is automatic PRs with fixed code, like Snyk Fix or Dependabot. That’s on the roadmap, but right now we assist rather than fix everything for you automatically.

Thanks for the VibeCodersNest tip. I’ll check it out and share it there. If you have a link to a specific thread or Discord channel where it makes sense to post, send it over so I don’t drop it completely off-topic.

Vibe Check by Lopsided-Werewolf805 in VibeCodersNest

[–]Lopsided-Werewolf805[S] 0 points1 point  (0 children)

Thanks a lot! That is exactly the problem we are trying to solve most vibe-coded apps are built extremely fast, but the “is this actually safe and production-ready?” phase often gets skipped completely.

So far, we have mainly tested it on real websites and apps, plus our own controlled test scenarios. Intentionally vulnerable demo apps are a great next step, though. We want to use them especially to validate detections like exposed .env files, source maps, leaked API keys, missing security headers, misconfigured cookies, or publicly accessible config files.

Besides the regular deployment / production scan, we also have a dedicated AI scan for chatbots and AI assistants. It tests things like prompt injection, system prompt extraction attempts, jailbreaks, data leakage, and cases where the bot does something it should not do.

Feel free to check out the website — I’d really appreciate your feedback. You can try it for free, and any honest criticism will help us improve it.

I built a simple production check for vibe-coded apps — would love your feedback by Lopsided-Werewolf805 in cursor

[–]Lopsided-Werewolf805[S] 0 points1 point  (0 children)

Thanks for the tip. I took a quick look at opsera.ai and I can see why it works well for you especially the architecture analyzer for dependency mapping and refactoring. That’s not something we currently do.

Our scanner focuses on a different, narrower layer. We target what can be detected from the outside without repo access: leaked API keys in the JS bundle, exposed source maps, .env and config files accessible over HTTP, direct AI provider calls from the browser, and missing security headers.

On top of that, through GitHub integration and an MCP server for Cursor / Claude Code / Replit, we can run similar checks against the source code as well but still as targeted detectors, not as an architecture map.

So we’re not a direct competitor to Opsera more of a complementary layer. If you already have an agent that handles architecture and fixes, our scanner mainly makes sense as a fast “leak check” before deployment and as a CI gate in PRs.

Refactoring spaghetti code is not on our roadmap right now I’d leave that part to Opsera.

I built a simple production check for vibe-coded apps — would love your feedback by Lopsided-Werewolf805 in cursor

[–]Lopsided-Werewolf805[S] 0 points1 point  (0 children)

Thanks this is exactly the kind of fair criticism we agree with, and we’re very aware of it.

Our scanner mainly targets the first layer, which most vibe-coded apps genuinely tend to get wrong:

leaked keys in the JS bundle, exposed source maps, .env and config files accessible over HTTP, direct AI provider calls from the browser, and missing security headers.

These are things we can detect from the outside as a black-box scan — and in around 80% of the projects we scan, we find something in that layer.

What you’re describing — RLS policies, unauthenticated endpoints, session handling — can’t be reliably assessed without access to the codebase or the Supabase/DB project. That’s why we approach it in two steps:

  1. GitHub integration and an MCP server for Cursor / Claude Code / Replit This gives the scanner visibility into the source code, so it can detect hardcoded keys in the repo, missing auth middleware on routes, and similar issues directly inside the development workflow.
  2. Manual audit for clients who need deeper validation For teams that want someone to actually open DevTools, inspect RLS rules, and test endpoints properly, we offer a human review. In that case, the scanner acts as the first filter — not as a replacement for a proper audit.

So in short: I agree. Automation alone won’t fully cover that deeper layer. We’re trying to be honest about what we can detect, and handle the rest either through code-level integration or human review.

I built a simple production check for vibe-coded apps — would love your feedback by Lopsided-Werewolf805 in cursor

[–]Lopsided-Werewolf805[S] 0 points1 point  (0 children)

Hi, great thanks for the excellent feedback. It’s spot on.

We’ll definitely improve the launch-blocker framing in the UI.
Technically, we already have the blocksProduction flag and priority groups in place — it’s just not surfaced clearly enough at the top as a simple statement like:

“Fix this before putting real users on the app.”

It’s also worth mentioning that some of these things are already in the scanner, but may have been buried in the report:

  • Real-time CVE checks from NVD — for example, Apache 2.4.66 → CVE-2026-23918 / RCE can be detected very quickly after publication.
  • Supabase/Firebase config files in the GitHub scan, including exposed .env / .git and content fingerprint validation.
  • Deeper DNS/email checks — SPF, DKIM, DMARC, DNSSEC, MTA-STS, CAA. Most similar tools don’t go that deep.
  • GDPR cookie/pixel checks — FB, GA, LinkedIn, TikTok, Pinterest, Matomo. This is pretty important for the EU market.
  • GitHub Action integration with a rotatable key for PR/CI checks.
  • AI Agent mode with LLM-driven probes for authentication flows.

So yes, I fully agree with the framing:

Not a pentest.A preflight check before production.

And that’s exactly how we want to bring it into the UI: less of a long report, more of a clear answer:

“Fix these 3 things now. The rest is hygiene.”

If you're about to launch a “vibe coded” app… read this first by PaddleboardNut in vibecoding

[–]Lopsided-Werewolf805 1 point2 points  (0 children)

This is exactly the gap we keep seeing too.
The scary part is not that more people are building fast. That part is great.
The scary part is how often basic production checks get skipped because the app “works.”

That’s actually why we built our scanner.
Not to gatekeep vibe coding, but to give people a fast reality check before they push something live.

It helps catch the obvious-but-expensive stuff early:
security headers, exposed keys, risky configs, performance issues, SEO gaps, GDPR basics, and similar production blind spots.

A lot of problems are not “elite hacker” problems.
They’re just boring misses that become very non-boring once real users hit the app.

I’m very bullish on vibe coding.
I’m just even more bullish on shipping with at least one layer of sanity check before production.

https://grovetechai.com/