How to Integrate Bolt.new with Norton LifeLock

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.

1# .env file in your Bolt project root
2# Have I Been Pwned API key (from haveibeenpwned.com/API/Key)
3HIBP_API_KEY=your_hibp_api_key_here
4
5# Google Safe Browsing API key (from console.cloud.google.com)
6GOOGLE_SAFE_BROWSING_KEY=your_google_api_key_here
7
8# Optional: VirusTotal API key (from virustotal.com)
9VIRUSTOTAL_API_KEY=your_virustotal_api_key_here

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.

1// app/api/security/breach-check/route.ts
2import { NextRequest, NextResponse } from 'next/server';
3
4export async function POST(request: NextRequest) {
5  const { email } = await request.json();
6
7  if (!email || !email.includes('@')) {
8    return NextResponse.json({ error: 'Invalid email address' }, { status: 400 });
9  }
10
11  const hibpApiKey = process.env.HIBP_API_KEY;
12  if (!hibpApiKey) {
13    return NextResponse.json({ error: 'Security API not configured' }, { status: 500 });
14  }
15
16  const url = `https://haveibeenpwned.com/api/v3/breachedaccount/${encodeURIComponent(email)}?truncateResponse=false`;
17
18  const response = await fetch(url, {
19    headers: {
20      'hibp-api-key': hibpApiKey,
21      'User-Agent': 'SecurityDashboard/1.0',
22    },
23  });
24
25  // 404 = no breaches found
26  if (response.status === 404) {
27    return NextResponse.json({ breaches: [], safe: true, count: 0 });
28  }
29
30  if (response.status === 429) {
31    return NextResponse.json(
32      { error: 'Too many requests — please wait a moment and try again' },
33      { status: 429 }
34    );
35  }
36
37  if (!response.ok) {
38    return NextResponse.json(
39      { error: `Breach check failed: ${response.status}` },
40      { status: response.status }
41    );
42  }
43
44  const breaches = await response.json();
45
46  const formatted = breaches.map((breach: any) => ({
47    name: breach.Name,
48    domain: breach.Domain,
49    breachDate: breach.BreachDate,
50    dataClasses: breach.DataClasses,
51    description: breach.Description,
52    isVerified: breach.IsVerified,
53    isSensitive: breach.IsSensitive,
54  }));
55
56  return NextResponse.json({
57    breaches: formatted,
58    safe: false,
59    count: formatted.length,
60  });
61}

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.

1// app/api/security/check-url/route.ts
2import { NextRequest, NextResponse } from 'next/server';
3
4export async function POST(request: NextRequest) {
5  const { url } = await request.json();
6
7  if (!url) {
8    return NextResponse.json({ error: 'URL is required' }, { status: 400 });
9  }
10
11  const apiKey = process.env.GOOGLE_SAFE_BROWSING_KEY;
12  if (!apiKey) {
13    return NextResponse.json({ error: 'Safe Browsing API not configured' }, { status: 500 });
14  }
15
16  const response = await fetch(
17    `https://safebrowsing.googleapis.com/v4/threatMatches:find?key=${apiKey}`,
18    {
19      method: 'POST',
20      headers: { 'Content-Type': 'application/json' },
21      body: JSON.stringify({
22        client: { clientId: 'security-dashboard', clientVersion: '1.0.0' },
23        threatInfo: {
24          threatTypes: ['MALWARE', 'SOCIAL_ENGINEERING', 'UNWANTED_SOFTWARE', 'POTENTIALLY_HARMFUL_APPLICATION'],
25          platformTypes: ['ANY_PLATFORM'],
26          threatEntryTypes: ['URL'],
27          threatEntries: [{ url }],
28        },
29      }),
30    }
31  );
32
33  if (!response.ok) {
34    return NextResponse.json({ error: 'URL check failed' }, { status: response.status });
35  }
36
37  const data = await response.json();
38  const threats = data.matches || [];
39
40  return NextResponse.json({
41    safe: threats.length === 0,
42    threats: threats.map((m: any) => m.threatType),
43    url,
44  });
45}

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.

1// components/BreachCard.tsx
2interface Breach {
3  name: string;
4  domain: string;
5  breachDate: string;
6  dataClasses: string[];
7  description: string;
8  isVerified: boolean;
9}
10
11const HIGH_SEVERITY_CLASSES = ['Passwords', 'Credit cards', 'Bank account numbers', 'Social security numbers'];
12
13export function BreachCard({ breach }: { breach: Breach }) {
14  const severity = breach.dataClasses.some(d => HIGH_SEVERITY_CLASSES.includes(d))
15    ? 'high'
16    : breach.dataClasses.includes('Email addresses')
17    ? 'medium'
18    : 'low';
19
20  const severityStyles = {
21    high: 'border-red-300 bg-red-50',
22    medium: 'border-yellow-300 bg-yellow-50',
23    low: 'border-gray-200 bg-gray-50',
24  };
25
26  const severityLabel = { high: 'High Risk', medium: 'Medium Risk', low: 'Low Risk' };
27
28  return (
29    <div className={`border rounded-lg p-4 ${severityStyles[severity]}`}>
30      <div className="flex justify-between items-start mb-2">
31        <div>
32          <h4 className="font-semibold">{breach.name}</h4>
33          <p className="text-sm text-gray-500">{breach.domain} · Breached {breach.breachDate}</p>
34        </div>
35        <span className={`text-xs font-medium px-2 py-1 rounded-full ${
36          severity === 'high' ? 'bg-red-100 text-red-700' :
37          severity === 'medium' ? 'bg-yellow-100 text-yellow-700' :
38          'bg-gray-100 text-gray-600'
39        }`}>
40          {severityLabel[severity]}
41        </span>
42      </div>
43      <div className="flex flex-wrap gap-1 mb-2">
44        {breach.dataClasses.map(dc => (
45          <span key={dc} className="text-xs bg-white border rounded px-2 py-0.5">{dc}</span>
46        ))}
47      </div>
48      {breach.dataClasses.includes('Passwords') && (
49        <p className="text-sm text-red-700 font-medium">
50          Action: Change your {breach.name} password immediately
51        </p>
52      )}
53    </div>
54  );
55}

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.