DEV Community: FlawPilot

A Developer-Friendly Workflow for Triaging Website Security Alerts

FlawPilot — Fri, 18 Sep 2026 07:40:14 +0000

A security scanner reports a missing header, an exposed key, an unsafe cookie, and a certificate warning. Which one should the team fix first?

The severity label helps, but it cannot answer that question by itself. A scanner does not know whether the affected asset is public, whether the credential is still valid, how many users depend on the service, or whether anyone is exploiting the weakness.

Developers need a repeatable way to turn scanner output into engineering work. The workflow below covers the full path: capture the evidence, validate it, decide whether the problem is an incident, assign an owner, make a safe change, and verify production.

Normalize the alert before discussing priority

Security tools describe findings in different ways. Before comparing them, put each alert into the same record format.

finding:
  title: "Public API key found in client-side JavaScript"
  asset: "https://example.com/assets/app.js"
  environment: "production"
  detected_at: "YYYY-MM-DD HH:MM UTC"
  scanner_severity: "high"
  evidence: "Key pattern and file location from the scan"

triage:
  publicly_reachable: true
  authentication_required: false
  sensitive_system_affected: "unknown"
  active_misuse_observed: "unknown"
  temporary_control_available: true

response:
  owner: "unassigned"
  status: "new"
  containment: "not started"
  permanent_fix: "not started"
  production_retest: "pending"

Do not place the full value of a secret, session token, or sensitive record in a general-purpose ticket. Record enough evidence to identify the issue, then store sensitive evidence in a restricted system.

This common format prevents several mistakes. It separates the scanner's assessment from the team's assessment. It also makes missing information visible instead of letting people assume that someone else checked it.

Validate the finding against the correct asset

Validation answers two questions:

Does the reported condition still exist?
Does the evidence point to the actual cause?

Start with the exact URL, hostname, file, port, certificate, DNS record, cookie, or response header named in the report. Confirm that it belongs to the intended environment.

Production and staging may behave differently because of:

CDN or reverse-proxy configuration
Environment-specific headers
Redirects between hostnames
Browser or edge caching
Different certificates
Feature flags
Old deployment assets

For an HTTP header finding, inspect the response returned by the public production URL. For a DNS finding, query the authoritative record rather than relying on an old screenshot. For a client-side exposure, inspect the deployed asset instead of checking only the current source branch.

Do not dismiss a finding because the page loads correctly. Missing cookie flags, loose cross-origin rules, and weak response headers often have no visible effect on the interface.

Separate a security finding from a security incident

A finding reports an unsafe or uncertain condition. An incident involves suspected or confirmed misuse, unauthorized access, data exposure, or service disruption.

A missing Content-Security-Policy header is normally a remediation task. A public credential with unexpected activity may require incident response.

Look for evidence such as:

Authentication events nobody recognizes
Requests made with an exposed credential
Unexpected administrative changes
Access to data outside an expected pattern
Unexplained traffic spikes or service disruption
Cloud, hosting, or repository alerts connected to the finding

If you see these signs, preserve relevant logs before making changes that could destroy evidence. Escalate according to the organization's incident process. An external website scan cannot determine what happened inside private accounts, logs, or authenticated workflows.

Prioritize with context, not severity alone

Use the scanner severity as one input. Then review four contextual factors.

Reachability

Can an unauthenticated person reach the affected asset from the public internet? A production endpoint that anyone can access usually deserves more attention than a private development service.

Impact

What could a successful misuse affect? Give more weight to findings connected to user sessions, privileged accounts, production credentials, payment paths, personal data, or administrative functions.

Preconditions

What must happen before the weakness can be used? A flaw that requires an authenticated administrator and an unusual configuration has different urgency from a working secret inside a public JavaScript bundle.

Current evidence

Is the risk theoretical, reproducible, or already being misused? Evidence of active misuse moves the work out of normal backlog prioritization.

After this review, place the finding into one of four action groups:

Contain now: suspected misuse, exposed credentials, unauthorized access, or active disruption
Fix next: public weakness with meaningful impact and a practical path to misuse
Schedule: missing defense or weak configuration with limited current exposure
Investigate: stale, duplicated, environment-specific, or unclear evidence

This classification is an engineering aid. It does not replace contractual, regulatory, or legal response requirements.

Assign the person who controls the affected system

An alert sent to an entire channel often has no owner. Assign one person to coordinate the next action and confirm that they accepted it.

Ownership usually follows the control:

Application developers own authentication logic, cookie settings, and application-level cross-origin behavior.
Platform or hosting owners handle response headers, redirects, certificates, public services, and edge configuration.
Domain or email administrators handle DNSSEC, CAA, SPF, DKIM, and DMARC.
The developer and service-account owner should work together when a credential is exposed.
A security or incident-response specialist should guide work when misuse or data exposure is possible.

The coordinator does not need to make every change. Their job is to keep the alert from becoming an unowned message thread.

Contain immediate risk before completing the repair

Containment reduces exposure while the team works on the root cause.

If a credential is public, revoke or rotate it. Deleting the value from the latest source file is not sufficient. Copies may remain in build artifacts, browser downloads, CDN caches, deployment history, logs, or Git history.

After rotation, restrict the replacement credential where possible:

Limit its permissions
Restrict allowed domains or IP addresses
Set usage limits
Separate production and development credentials
Enable provider-side monitoring

If a route or service appears to be under active attack, a temporary response may include disabling the route, restricting access, adding a narrow web application firewall rule, or rolling back a release.

Containment is not closure. Keep the task open until the team fixes the cause and verifies the live system.

Make the smallest safe change

Broad configuration changes can break authentication, payments, analytics, embedded tools, or third-party scripts.

Content Security Policy is a common example. Copying a strict policy from an unrelated site may block resources your application needs. Build the policy around the actual scripts, frames, styles, fonts, and connections used by your application. Test the affected user journeys before enforcing it in production.

Apply the same discipline to:

Cross-origin resource sharing rules
Cookie attributes
Redirect behavior
Cache controls
TLS and certificate changes
DNS records
Storage permissions

Use staging when it represents production accurately. Prepare a rollback path for changes that affect traffic, authentication, or external integrations.

Retest the public result after deployment

A merged pull request does not prove that the finding disappeared from production.

The application may still serve an old asset or cached response. The change may exist only in staging. A configuration file may not be connected to the active service.

Use this verification sequence:

Deploy the change through the normal release process.
Repeat the original check against the same production asset.
Confirm that the original evidence is gone.
Test the user journey that depends on the changed control.
Check for new warnings or broken behavior.
Attach the new evidence to the ticket.

Close the task only when the production result matches the intended state.

Use a reusable remediation issue template

The following Markdown template works in most issue trackers:

## Finding

- Title:
- Affected asset:
- Environment:
- Detected at:
- Scanner severity:
- Evidence location:

## Validation

- [ ] Correct asset and environment confirmed
- [ ] Finding reproduced or independently verified
- [ ] False-positive conditions reviewed
- [ ] Sensitive evidence stored securely

## Triage

- Publicly reachable: Yes / No / Unknown
- Authentication required: Yes / No / Unknown
- Potential impact:
- Preconditions:
- Signs of active misuse: Yes / No / Unknown
- Action group: Contain now / Fix next / Schedule / Investigate

## Ownership

- Coordinator:
- Technical owner:
- Target date:
- Escalation contact:

## Response

- Containment action:
- Root cause:
- Permanent fix:
- Rollback plan:

## Verification

- Production deployment:
- Original check repeated:
- User journey tested:
- New issues found:
- Evidence attached:
- Final status:

Adjust the fields to match the team's incident process and access controls. Avoid copying secrets or personal data into the issue.

Define the workflow before the next alert

Write down who reviews new findings, where the team records them, and which conditions start an incident response. Document who can rotate credentials, change DNS, update hosting configuration, and deploy emergency fixes.

The policy should also define how the team accepts a known risk and when the same asset will be checked again. A finding should not disappear simply because the current sprint ended.

NIST SP 800-61 Revision 3 connects preparation, detection, response, and recovery. A small team may combine several roles, but it still needs clear ownership and an escalation path.

Closing thought

Scanner output is evidence, not a completed decision. Validate the affected asset, add technical and business context, and assign a person who can move the work forward.

For urgent exposure, contain first. For normal remediation, make a controlled change and retest the public system. The alert is resolved only when production evidence confirms the fix.

This article is adapted from an original guide published on FlawPilot. It contains no affiliate links or paid placement.

Lovable App Security We Scanned a Real App and Found 29 Open Issues

FlawPilot — Fri, 14 Aug 2026 12:29:29 +0000

Quick answer: Lovable app security's most common failure isn't a missing header. It's an unset Supabase Row-Level Security policy. Skip it and the app still works, because the query still succeeds, just for anyone, not only its owner. We scanned a real Lovable app and found exactly that gap, live.

Picture the app you shipped last sprint. You described a dashboard, Lovable wired up the tables, the auth, the UI, and it all just worked the first time you clicked through it. That's the whole appeal. It's also exactly why nobody goes back and checks the one setting that doesn't announce itself when it's missing. So we did. We took a real, live Lovable app, built the way most Lovable apps get built (fast, from a prompt, shipped the same week), and ran it through FlawPilot, a free scan that checks a site's security, performance, infrastructure, and SEO in about two minutes, no login required. We won't name the app, but every number below is real, pulled straight from its report.

The scorecard

63 out of 100. "At risk." 252 points out of a possible 400, and 29 things sitting open: 1 critical, 5 high, 15 medium, 8 low.

Split out:

Security: 55/100. At risk. 13 findings.
Performance: 96/100. Excellent. 2 findings.
Infrastructure: 58/100. At risk. 9 findings.
SEO & Discoverability: 62/100. Needs attention. 5 findings.

Nothing was defaced. The app looked, and behaved, exactly like it was supposed to. That's the part worth sitting with: every screen worked, every click did the right thing, and the one critical finding on this report had never once shown up as a bug.

What it got right

96/100 on performance is close to a clean sweep. Lovable's scaffolding leans on Vite and React defaults that are already fast out of the box: quick first paint, sensible bundle size, nothing render-blocking that shouldn't be.

Which is exactly the trap. A fast, polished frontend is the thing you notice with your own eyes, so it's the thing that gets credited as "done." Everything below is the kind of gap that only shows up once something outside the team, a scanner, a bot, or someone who isn't supposed to, goes looking for it on purpose.

What was hiding underneath

A Supabase table had no Row-Level Security policy at all. Rated Critical, and it's the finding that matters most on this whole report. Lovable apps run on Supabase by default, and Supabase enforces access at the database layer through RLS policies, not through the app's own login screen. Turn RLS on for a table and the database itself checks who's allowed to see which row. Leave it off, and the table is exactly as open as the anon key that ships in every Lovable app's JS bundle: open to anyone who opens dev tools and watches a single network request. This app's login screen worked correctly the whole time. The database behind it never checked whether the person asking was allowed to see the data they were asking for.

The fix, in Supabase, is two SQL statements:

-- Enable Row-Level Security on the table
ALTER TABLE public.orders ENABLE ROW LEVEL SECURITY;

-- Scope reads to the row's own owner
CREATE POLICY "Users can view their own orders"
ON public.orders
FOR SELECT
USING (auth.uid() = user_id);

No rewrite, no data migration, just a policy that tells the database who's allowed to see which row instead of trusting the app's UI to gate it for you. Repeat per table, per operation (SELECT, INSERT, UPDATE, DELETE) as needed.

The rest of the report was more familiar territory:

No DMARC record: anyone could send email pretending to be this domain (High)
No Content-Security-Policy header: an injected script has nowhere to be stopped (High)
No Strict-Transport-Security header: first request can get downgraded to plain HTTP (High)
No clickjacking protection: the app can be framed invisibly inside another page (High)
No CAA record: any certificate authority could issue a cert for the domain (Medium)
No DKIM signature: outgoing mail at real risk of landing in spam (Medium)
Missing sitemap.xml, thin meta descriptions: dragged the SEO score to 62 (Medium)
Verbose error pages left on: handing back stack traces to anyone who triggers one (Medium)

None of this showed up while clicking through the app. All of it shows up the moment something outside the team, a scanner, a bot, an attacker, bothers to check.

Why this is the default, not a fluke

That combination, an unset RLS policy sitting next to missing headers and no DMARC, is close to the single most repeated pattern across Lovable apps specifically. Lovable isn't careless, it's optimizing for "the prompt works," and a Supabase table without an RLS policy still returns exactly the data you asked for in testing. The query succeeds either way. Nothing about that failure looks like a failure until someone sends a request the app wasn't expecting.

This isn't hypothetical. In March 2025, this exact gap, missing RLS in Lovable-generated apps, was catalogued as CVE-2025-48757 (CVSS base score 8.26, High), and left more than 170 live production apps with databases any unauthenticated visitor could read, write to, or delete from, just by inspecting the app's own network requests. Nobody shipped a bug that broke anything. The gap was a security control nobody had reason to think about, sitting quietly under apps that worked perfectly for months.

The broader research backs this up. Veracode's GenAI Code Security testing has run over 100 models across 80 coding tasks over four years, and the average pass rate on a security review has held at roughly 56%, meaning close to 44% of AI-generated code fails a review outright. A 2023 Stanford study (Perry et al., ACM CCS) found the same pattern at the human level: developers using an AI coding assistant wrote measurably less secure code than developers working without one, and felt more confident about it, not less. The role that used to catch an unset RLS policy, a senior engineer flagging it in code review, mostly doesn't exist in a Lovable workflow, because there's often no review step between describing the app and the app going live.

How to actually fix this

A severity label is only useful if it turns into something you actually do. Here's how FlawPilot handles that on this exact report.

Every finding gets grouped by area and dropped into a ranked "What to do next" list, not a raw dump of jargon. Item one was the RLS finding, and next to it, in plain English: enable Row-Level Security on this table and add a policy scoping rows to the authenticated user.

Four of the five High findings here (CSP, HSTS, clickjacking, DMARC) are pure configuration, no application logic involved. The RLS fix is a Supabase policy, not a rewrite. Clear those five and close out the CAA and DKIM gaps next to them, and a security score that opened at 55 is realistically headed for the 90s.

Try it on your own app

No setup, no coding, no passwords required. Drop in a URL, and in about two minutes you get a full scorecard: security, performance, infrastructure, and SEO, each out of 100, every finding in plain English, with a toggle between a plain-language view and the full technical one.

Scan your Lovable app for free →

FAQ

Is Lovable secure by default?
Not fully. Lovable handles HTTPS and gets you a working auth flow fast, but Row-Level Security on your Supabase tables is opt-in, and HTTP security headers, DMARC, and DNS hardening aren't configured automatically either.

What's the single most common Lovable security issue?
A Supabase table with no Row-Level Security policy, also the most severe, since it can leave underlying data readable or writable by anyone.

Does scanning my site give FlawPilot access to my Supabase project?
No. The scan only checks publicly accessible signals, the same things any browser or bot on the internet can already see. It never touches your Supabase dashboard, your database directly, or your credentials.

Can I fix this myself without hiring anyone?
Header, DNS, and email-authentication fixes usually live in your hosting or DNS provider's dashboard. The RLS fix lives in your Supabase project's SQL editor or policy UI and takes minutes once you know which table needs it.

How often should I actually check this?
Before anything you'd call a real release, and again any time you add a new table, since a new table means RLS is opt-in again.

The app worked the whole time. The database behind it never once did. That gap is the part worth remembering long after the specific header names and CVE numbers fade: "it works" and "it's secure" get checked by two different questions, and only one of them shows up on screen.