# How to Integrate Bolt.new with Norton LifeLock

- Tool: Bolt.new
- Difficulty: Intermediate
- Time required: 20 minutes
- Last updated: April 2026

## TL;DR

Norton (Gen Digital) and LifeLock are consumer security products with no public developer APIs. To add identity protection features to your Bolt.new app, use Have I Been Pwned API to check email breach status, Google Safe Browsing API to validate URL safety, or Auth0/Okta for secure authentication. Prompt Bolt to build a security dashboard using the Have I Been Pwned free API — it requires no key for the basic endpoint and works directly in Bolt's WebContainer preview.

## Build Identity Protection Features in Bolt.new Using Security APIs (Not Norton)

Norton LifeLock (rebranded Gen Digital in 2022) is a well-known consumer security brand, but it does not offer public APIs for developers to integrate its services into applications. LifeLock's identity monitoring, dark web scanning, and credit monitoring are consumer subscription products — not developer services. If you need security features in your Bolt.new app, you need purpose-built security APIs designed for developers.

The most useful security APIs for Bolt.new developers are Have I Been Pwned (HIBP), which checks whether an email address or password has appeared in known data breaches. The HIBP API is free for basic queries — checking a single email requires no API key and returns a list of breach names with dates. The paid API key tier ($3.50/month) adds higher rate limits and bulk checking. This is the closest equivalent to LifeLock's breach monitoring feature that you can build yourself.

For URL safety checking (similar to Norton Safe Web), Google Safe Browsing API is the industry standard — it is the same API that Chrome and Firefox use to block malicious websites. It is free for up to 10,000 API calls per day. VirusTotal provides file and URL scanning against 70+ antivirus engines. For authentication security specifically, Auth0 and Okta offer enterprise-grade identity protection (MFA, anomaly detection, suspicious login alerts) that replaces the need for Norton's identity monitoring at the authentication layer.

## Before you start

- A Have I Been Pwned API key from haveibeenpwned.com/API/Key (optional for basic use, required for higher rate limits)
- A Google Cloud project with the Safe Browsing API enabled for URL threat checking (free tier available)
- A Bolt.new project with Supabase connected for storing security check results and user data
- Basic understanding of API routes in Next.js for keeping API keys server-side

## Step-by-step guide

### 1. Set Up Have I Been Pwned API Access

Have I Been Pwned (HIBP) is the most authoritative and widely-used breach database, created by security researcher Troy Hunt. The API checks whether an email address appears in any of over 12 billion compromised accounts across thousands of data breaches.

For basic email breach checking, the HIBP API works without an API key — you can make authenticated requests by passing a `hibp-api-key` header with a value of 'none' for testing, though in practice the unauthenticated endpoint may be rate-limited. For production apps, get an API key at haveibeenpwned.com/API/Key — it costs $3.50/month and provides higher rate limits (50 requests per minute) plus access to the paste check endpoint and subscription monitoring.

The HIBP API also includes a k-Anonymity password checker — instead of sending the full password hash to HIBP, you send only the first 5 characters of the SHA-1 hash, and HIBP returns all hashes with those 5 characters. Your app checks if the full hash is in the returned list without HIBP ever seeing the complete hash. This is the technically correct way to implement password breach checking in Bolt.new.

Another excellent security API is VirusTotal (virustotal.com/vt/docs). The free tier allows 500 API calls per day and 4 per minute. You can use it to scan URLs, file hashes, domains, and IP addresses against 70+ antivirus engines. The API key is available instantly after account creation at virustotal.com.

```
# .env file in your Bolt project root
# Have I Been Pwned API key (from haveibeenpwned.com/API/Key)
HIBP_API_KEY=your_hibp_api_key_here

# Google Safe Browsing API key (from console.cloud.google.com)
GOOGLE_SAFE_BROWSING_KEY=your_google_api_key_here

# Optional: VirusTotal API key (from virustotal.com)
VIRUSTOTAL_API_KEY=your_virustotal_api_key_here
```

**Expected result:** You have security API credentials configured in .env and understand the difference between breach checking (HIBP), URL scanning (Google Safe Browsing), and file scanning (VirusTotal).

### 2. Build the Breach Check API Route

The breach check API route queries HIBP with a user's email address and returns a structured list of data breaches. Since the HIBP API requires your API key, the route must run server-side — never expose the API key in client-facing code.

HIBP's breach check endpoint is `GET https://haveibeenpwned.com/api/v3/breachedaccount/{email}`. It returns an array of breach objects when breaches are found, or a 404 status when the email is clean. The response includes the breach name, domain, breach date, description, and the types of data exposed (DataClasses array: passwords, email addresses, phone numbers, etc.).

The `truncateResponse=false` parameter returns full breach details including descriptions. Without it, HIBP returns only breach names. For a user-facing security dashboard, full details are essential — users need to know which specific sites were breached and what data was exposed to understand the severity.

Bolt's WebContainer can make the outbound HIBP API call during development — this is a standard HTTP GET request that works from the preview. You can test breach checking in the preview before deploying. Rate limiting applies even during development, so avoid rapid repeated testing with the same email address.

```
// app/api/security/breach-check/route.ts
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const { email } = await request.json();

  if (!email || !email.includes('@')) {
    return NextResponse.json({ error: 'Invalid email address' }, { status: 400 });
  }

  const hibpApiKey = process.env.HIBP_API_KEY;
  if (!hibpApiKey) {
    return NextResponse.json({ error: 'Security API not configured' }, { status: 500 });
  }

  const url = `https://haveibeenpwned.com/api/v3/breachedaccount/${encodeURIComponent(email)}?truncateResponse=false`;

  const response = await fetch(url, {
    headers: {
      'hibp-api-key': hibpApiKey,
      'User-Agent': 'SecurityDashboard/1.0',
    },
  });

  // 404 = no breaches found
  if (response.status === 404) {
    return NextResponse.json({ breaches: [], safe: true, count: 0 });
  }

  if (response.status === 429) {
    return NextResponse.json(
      { error: 'Too many requests — please wait a moment and try again' },
      { status: 429 }
    );
  }

  if (!response.ok) {
    return NextResponse.json(
      { error: `Breach check failed: ${response.status}` },
      { status: response.status }
    );
  }

  const breaches = await response.json();

  const formatted = breaches.map((breach: any) => ({
    name: breach.Name,
    domain: breach.Domain,
    breachDate: breach.BreachDate,
    dataClasses: breach.DataClasses,
    description: breach.Description,
    isVerified: breach.IsVerified,
    isSensitive: breach.IsSensitive,
  }));

  return NextResponse.json({
    breaches: formatted,
    safe: false,
    count: formatted.length,
  });
}
```

**Expected result:** Posting an email to /api/security/breach-check returns either { safe: true, breaches: [] } or a list of breach objects with names, dates, and exposed data types.

### 3. Build the URL Safety Check with Google Safe Browsing

Google Safe Browsing is the API that powers the 'Deceptive site ahead' warnings in Chrome, Firefox, and Safari. Integrating it into your Bolt.new app lets you validate URLs before storing them in your database or presenting them to users — catching phishing, malware distribution, and social engineering attacks.

The Google Safe Browsing API v4 endpoint is a POST request to `https://safebrowsing.googleapis.com/v4/threatMatches:find?key=[YOUR_API_KEY]`. The request body specifies the threat types to check against (MALWARE, SOCIAL_ENGINEERING, UNWANTED_SOFTWARE, POTENTIALLY_HARMFUL_APPLICATION) and the URL to check. If the URL is flagged, the response includes which threat types it triggered.

To enable the Google Safe Browsing API, go to Google Cloud Console (console.cloud.google.com), create or select a project, navigate to APIs & Services → Library, search for Safe Browsing API, and enable it. Create an API key under APIs & Services → Credentials. The Safe Browsing API is free for up to 10,000 API calls per day — more than enough for most Bolt apps.

In Bolt's WebContainer, the Safe Browsing API call works as an outbound HTTP POST request. You can test URL scanning in the preview. For production, the API key should be in your .env file and accessed through a Next.js API route — never in client-side code since the key has no domain restrictions by default and could be misused.

```
// app/api/security/check-url/route.ts
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const { url } = await request.json();

  if (!url) {
    return NextResponse.json({ error: 'URL is required' }, { status: 400 });
  }

  const apiKey = process.env.GOOGLE_SAFE_BROWSING_KEY;
  if (!apiKey) {
    return NextResponse.json({ error: 'Safe Browsing API not configured' }, { status: 500 });
  }

  const response = await fetch(
    `https://safebrowsing.googleapis.com/v4/threatMatches:find?key=${apiKey}`,
    {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        client: { clientId: 'security-dashboard', clientVersion: '1.0.0' },
        threatInfo: {
          threatTypes: ['MALWARE', 'SOCIAL_ENGINEERING', 'UNWANTED_SOFTWARE', 'POTENTIALLY_HARMFUL_APPLICATION'],
          platformTypes: ['ANY_PLATFORM'],
          threatEntryTypes: ['URL'],
          threatEntries: [{ url }],
        },
      }),
    }
  );

  if (!response.ok) {
    return NextResponse.json({ error: 'URL check failed' }, { status: response.status });
  }

  const data = await response.json();
  const threats = data.matches || [];

  return NextResponse.json({
    safe: threats.length === 0,
    threats: threats.map((m: any) => m.threatType),
    url,
  });
}
```

**Expected result:** Submitting a URL to the safety checker returns a safe/unsafe status with the specific threat types detected (MALWARE, SOCIAL_ENGINEERING, etc.).

### 4. Assemble the Security Dashboard UI

Combine the breach checker and URL scanner into a cohesive security dashboard that gives users actionable information about their account security. The dashboard should show: current breach status for the user's email, a URL safety scanner for checking suspicious links, active session management (from Supabase Auth), and security recommendations.

For the breach status section, store the last breach check result and timestamp in the user's Supabase profile. Display the cached result and a 'Check Now' button to refresh. Showing the last check date helps users understand whether the data is current — HIBP is updated in near-real-time as new breaches are discovered, so re-checking every few days provides fresh information.

For each breach displayed, show the breach severity based on the data classes exposed. Breaches containing passwords and financial data are most severe — indicate this with a visual urgency level. For each breach, provide an actionable recommendation: 'Change your password on [Service Name]' or 'Enable 2FA on accounts using this email'.

The URL scanner section works well as a floating tool accessible from any page — a compact input in the sidebar or header that lets users quickly check any link before clicking it. This is especially valuable for apps where users share links in comments, messages, or collaborative documents.

```
// components/BreachCard.tsx
interface Breach {
  name: string;
  domain: string;
  breachDate: string;
  dataClasses: string[];
  description: string;
  isVerified: boolean;
}

const HIGH_SEVERITY_CLASSES = ['Passwords', 'Credit cards', 'Bank account numbers', 'Social security numbers'];

export function BreachCard({ breach }: { breach: Breach }) {
  const severity = breach.dataClasses.some(d => HIGH_SEVERITY_CLASSES.includes(d))
    ? 'high'
    : breach.dataClasses.includes('Email addresses')
    ? 'medium'
    : 'low';

  const severityStyles = {
    high: 'border-red-300 bg-red-50',
    medium: 'border-yellow-300 bg-yellow-50',
    low: 'border-gray-200 bg-gray-50',
  };

  const severityLabel = { high: 'High Risk', medium: 'Medium Risk', low: 'Low Risk' };

  return (
    <div className={`border rounded-lg p-4 ${severityStyles[severity]}`}>
      <div className="flex justify-between items-start mb-2">
        <div>
          <h4 className="font-semibold">{breach.name}</h4>
          <p className="text-sm text-gray-500">{breach.domain} · Breached {breach.breachDate}</p>
        </div>
        <span className={`text-xs font-medium px-2 py-1 rounded-full ${
          severity === 'high' ? 'bg-red-100 text-red-700' :
          severity === 'medium' ? 'bg-yellow-100 text-yellow-700' :
          'bg-gray-100 text-gray-600'
        }`}>
          {severityLabel[severity]}
        </span>
      </div>
      <div className="flex flex-wrap gap-1 mb-2">
        {breach.dataClasses.map(dc => (
          <span key={dc} className="text-xs bg-white border rounded px-2 py-0.5">{dc}</span>
        ))}
      </div>
      {breach.dataClasses.includes('Passwords') && (
        <p className="text-sm text-red-700 font-medium">
          Action: Change your {breach.name} password immediately
        </p>
      )}
    </div>
  );
}
```

**Expected result:** The security dashboard shows breach status with severity levels, URL scanner results, and account activity data in a cohesive interface.

### 5. Deploy and Protect Security API Keys

Security-related apps have higher than average stakes when it comes to protecting API keys and user data. Before deploying, audit the generated code to ensure no API keys appear in client-side components — the breach check and URL safety API keys must only appear in server-side API routes accessed via `process.env`.

Deploy to Netlify or Bolt Cloud by clicking Publish. After deployment, add environment variables to your hosting platform: `HIBP_API_KEY` and `GOOGLE_SAFE_BROWSING_KEY`. In Netlify, use Site Configuration → Environment Variables. In Bolt Cloud, use the Secrets panel. Trigger a redeploy after adding variables.

For the breach data specifically, Bolt's WebContainer cannot receive incoming connections, so any feature that pushes security alerts to users in real time (like a browser extension that checks breaches on login) would require a deployed server. The standard pull model (user visits the dashboard and clicks Check Now) works fine with either the preview or deployed version since it is purely outbound calls.

Ensure the breach check results stored in Supabase have proper RLS policies — a user's breach history is sensitive personal data and should only be accessible to that specific user, never to other users or unauthenticated requests. Add an RLS policy: `USING (auth.uid() = user_id)` on the security_checks table.

**Expected result:** The deployed security dashboard loads breach check cache instantly on page load and allows manual refresh. API keys are securely stored as environment variables and never appear in client code.

## Best practices

- Never ask users to enter their actual password into your breach checker — use HIBP's k-anonymity password API which checks without exposing the password
- Cache breach check results per user in Supabase with a timestamp — checking once per day is sufficient and avoids hitting HIBP rate limits
- Add RLS policies on any tables storing security check results — breach data is sensitive personal information that must be isolated per user
- Display breach severity clearly — expose which data types were compromised (passwords vs email vs phone) with actionable recommendations, not just a breach count
- Never expose Google Safe Browsing or HIBP API keys in client-side code — proxy all security API calls through Next.js API routes
- Add rate limiting to your breach check API route — limit each user to 5 checks per hour to protect your HIBP API quota
- Make security features optional and privacy-respecting — always explain to users what data is being sent to external APIs before checking

## Use cases

### Email Breach Status Checker

Allow users to check if their email address has appeared in any known data breaches. Enter an email, call Have I Been Pwned, and display a list of affected services with breach dates and types of exposed data (passwords, phone numbers, addresses). Users can see their breach history at a glance and take action on exposed accounts.

Prompt example:

```
Build a breach checker tool using the Have I Been Pwned API. Create a form with an email input. When submitted, call an API route that fetches https://haveibeenpwned.com/api/v3/breachedaccount/[email]?truncateResponse=false with a User-Agent header and my HIBP_API_KEY from process.env. Display the results as a list of breach cards showing: service name, breach date, types of data exposed (passwords, emails, phone numbers), and whether the breach is verified. Show a green 'No breaches found' state or a red 'X breaches found — take action' alert.
```

### URL Safety Scanner

Before users submit links in your app (in comments, profile fields, or shared resources), scan them against Google Safe Browsing to detect malware, phishing, and social engineering threats. Block or warn users before they visit flagged URLs.

Prompt example:

```
Add URL safety checking to my app's link submission feature. Create an API route at app/api/security/check-url/route.ts that accepts a URL and checks it against the Google Safe Browsing API (https://safebrowsing.googleapis.com/v4/threatMatches:find) using GOOGLE_SAFE_BROWSING_KEY from process.env. If the URL is flagged as malware, phishing, or social engineering, return a warning object. If clean, return a safe status. Use this API route to validate any user-submitted URLs before saving them to Supabase.
```

### Security Dashboard for User Accounts

Show users a security status panel in their account settings: breach exposure status for their email, password strength indicator, last login date and IP, devices linked to their account, and active sessions. Users can revoke sessions and get actionable recommendations for improving their account security.

Prompt example:

```
Build a security dashboard at /settings/security. Show: (1) Breach status — check the user's email against HIBP API and show total breach count with a 'Check Now' refresh button, (2) Active sessions — query Supabase auth.sessions for the current user and list each session with device info and 'Revoke' button, (3) Last login — show last_sign_in_at from Supabase auth.users, (4) Password strength — show a recommendation to enable 2FA if not already enabled. Style it as a clean security card with red/yellow/green status indicators.
```

## Troubleshooting

### HIBP API returns 401 Unauthorized

Cause: The HIBP API key is missing from environment variables, or the key is expired or deactivated. HIBP v3 requires an API key for all breach account searches — unauthenticated requests to the breach check endpoint return 401.

Solution: Verify HIBP_API_KEY is set in your .env file locally and in your hosting platform's environment variables for production. Check your HIBP account at haveibeenpwned.com to confirm the key is active. The API key must be passed in the 'hibp-api-key' request header, not as a query parameter or in the Authorization header.

```
// Correct HIBP authentication header
const response = await fetch(url, {
  headers: {
    'hibp-api-key': process.env.HIBP_API_KEY!,  // Specific header name required
    'User-Agent': 'YourApp/1.0',  // User-Agent is also required
  },
});
```

### Google Safe Browsing returns 400 Bad Request

Cause: The request body format is incorrect. Google Safe Browsing requires specific field names (threatTypes, platformTypes, threatEntryTypes as arrays) and the URL must be in a threatEntries array of objects with a 'url' key.

Solution: Verify your request body matches the exact Google Safe Browsing API v4 format. Common mistakes: using string instead of array for threatTypes, missing the platformTypes field, or passing a plain URL string instead of `{ url: 'https://...' }` in the threatEntries array. Test your request body format with the Google API Explorer at developers.google.com.

```
// Correct Safe Browsing request body structure
body: JSON.stringify({
  client: { clientId: 'my-app', clientVersion: '1.0' },
  threatInfo: {
    threatTypes: ['MALWARE', 'SOCIAL_ENGINEERING'],  // Array, not string
    platformTypes: ['ANY_PLATFORM'],               // Required field
    threatEntryTypes: ['URL'],                      // Array
    threatEntries: [{ url: urlToCheck }],           // Object with url key
  },
})
```

### Breach check shows results in preview but returns 403 in production

Cause: HIBP's API terms require that your app's User-Agent header identifies your application. Some hosting environments strip or modify User-Agent headers, causing HIBP to reject the request.

Solution: Ensure your API route sets a descriptive User-Agent header: 'User-Agent': 'YourAppName/1.0'. Check that the deployed API route is actually passing this header — some middleware or proxy configurations strip custom headers. Add the User-Agent to your fetch call explicitly and verify it appears in the outgoing request using Netlify's function logs.

## Frequently asked questions

### Does Norton or LifeLock have a developer API I can use in Bolt.new?

No. Norton (Gen Digital) and LifeLock are consumer products without public developer APIs. Their identity monitoring, dark web scanning, and credit monitoring are subscription services for end users, not APIs for developers. For breach monitoring in Bolt apps, use Have I Been Pwned. For URL safety, use Google Safe Browsing.

### Is it safe to send user email addresses to Have I Been Pwned?

Yes. HIBP is operated by Troy Hunt, a respected security researcher, and is widely trusted including by governments and enterprises. The service only checks breach databases and does not store query emails. HIBP's API privacy policy confirms email addresses are not retained after the check. Always inform your users that their email will be checked against a third-party breach database before calling the API.

### Do breach checks work in Bolt's WebContainer preview?

Yes. HIBP and Google Safe Browsing API calls are outbound HTTP requests from your server-side API route. Bolt's WebContainer supports outbound HTTP calls during development, so you can test breach checking in the preview without deploying. The HIBP API rate limit applies during development, so avoid rapid repeated testing.

### How do I check passwords for breaches without exposing them?

Use HIBP's k-anonymity password API at api.pwnedpasswords.com/range/[first5HashChars]. Hash the password client-side with SHA-1, take the first 5 characters of the hex hash, send those to HIBP, and check if the full hash appears in the returned list. HIBP never sees the full hash. Implement this entirely client-side — no API key required and no server-side call needed for password checking.

### Can I monitor users continuously for new breaches like LifeLock does?

HIBP offers an email notification API subscription for monitoring specific addresses continuously — it sends notifications when a new breach includes a monitored email. This requires a higher-tier API key and registration of email addresses to monitor. Alternatively, build a daily scheduled job (via Supabase's pg_cron or a cron hosting service) that re-checks all registered user emails against HIBP and sends an email notification on new breach detection.

---

Source: https://www.rapidevelopers.com/bolt-ai-integrations/norton-lifelock
© RapidDev — https://www.rapidevelopers.com/bolt-ai-integrations/norton-lifelock