B-80%
Quality Score
7
Pages
135
Issues
8.0
Avg Confidence
7.8
Avg Priority
61 Critical45 High29 Medium
>_ Testers.AI
AI Analysis
Kfc.Co was tested and 135 issues were detected across the site. The most critical finding was: Hardcoded Google Maps API key exposed in client-side request. Issues span Security, A11y, Performance, Other categories. Persona feedback rated Visual highest (7/10) and Accessibility lowest (5/10).
Qualitative Quality
Kfc.Co
Category Avg
Best in Category
Pages Tested · 7 screenshots
Homepage
www.kfc.co
www.kfc.co
www.kfc.co
www.kfc.co
www.kfc.co
www.kfc.co
Detected Issues · 135 total
1
Hardcoded Google Maps API key exposed in client-side request
CRIT P10
Prompt to Fix
Actionable fix: Remove the hardcoded Google Maps API key from the client. Implement a secure key management strategy by storing the key in server-side environment variables or a restricted API key with referrer restrictions, and proxy map requests through a backend endpoint. Ensure the frontend never exposes the raw API key in URLs or source code.
Why it's a bug
The network log shows a Google Maps API script URL containing an actual API key (key=AIzaSyCUUkqFamwWg61akQdEXVRdg5lOB5jkCY0). Exposing API keys in client-side code risks abuse, quota drain, and credential leakage. Keys should be restricted, rotated, and never committed to front-end code.
Why it might not be a bug
If this is a placeholder or test environment key with strict HTTP referrer restrictions, the risk is reduced, but the log suggests a real-looking key being used in production-like context. Treat as high risk until confirmed.
Suggested Fix
Move the API key to a secure backend environment or use a restricted API key with proper HTTP referrer and API restrictions. Consider proxying Google Maps requests through a server you control or loading maps with a key managed via environment variables. Remove any hardcoded keys from client bundles and implement key rotation.
Why Fix
Prevents credential leakage, mitigates abuse (e.g., quota theft), and aligns with best security practices for API keys in frontend applications.
Route To
Security Engineer / Frontend Engineer
Page
Tester
Jason · GenAI Code Analyzer
Technical Evidence
Console:
GET https://maps.googleapis.com/maps/api/js?callback=__googleMapsCallback&key=AIzaSyCUUkqFamwWg61akQdEXVRdg5lOB5jkCY0&libraries=places&v=weekly - Status: N/ANetwork:
GET https://maps.googleapis.com/maps/api/js?callback=__googleMapsCallback&key=AIzaSyCUUkqFamwWg61akQdEXVRdg5lOB5jkCY0&libraries=places&v=weekly2
Unconsented Facebook Pixel tracking script loaded (fbevents.js)
CRIT P9
Prompt to Fix
Wrap the Facebook Pixel script loading in a consent check. Only inject <script src="https://connect.facebook.net/en_US/fbevents.js"> after user enables analytics cookies. Do not initialize fbq() or send events until consent is granted. Provide a code snippet that dynamically loads the script after consent and clears any pending events if consent is denied.
Why it's a bug
The page loads Facebook Pixel analytics (fbevents.js), enabling cross-site user tracking without clear consent indicators. This can lead to user profiling and data sharing with a third party without explicit user permission.
Why it might not be a bug
If a robust Consent Management Platform (CMP) is in place and analytics scripts load only after user consent, this would not be a bug. The provided data does not show consent gating for this script.
Suggested Fix
Gate loading of Facebook Pixel behind explicit user consent for analytics/tracking. Use a CMP to conditionally inject the fbevents.js script after consent, and ensure no dataLayer events are sent until consent is granted. Consider enabling Consent Mode if using Google tags.
Why Fix
Prevents unconsented cross-site tracking and aligns with privacy regulations and user expectations around data collection.
Route To
Frontend Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Network:
https://connect.facebook.net/en_US/fbevents.js3
On-load AI/LLM endpoint detected and invoked
CRIT P9
Prompt to Fix
Actionable fix: Refactor the page so that any AI/LLM network requests are not fired on initial load. Add a user consent mechanism (e.g., a banner or modal) that explains what data will be sent to AI services. Implement a lazy-loading pattern for AI calls with a lightweight placeholder UI, scrub all PII before sending, and route requests through a secure backend with proper authentication and data-handling policies. Update documentation to reflect when and why AI endpoints are used.
Why it's a bug
The console shows a visible indicator '⚠️ AI/LLM ENDPOINT DETECTED', suggesting AI/LLM calls are being made as the page loads. This can lead to unintended data being sent to external AI services, potential privacy violations, performance degradation on initial paint, and unclear user consent for data sharing.
Why it might not be a bug
If the AI call is essential for early functionality (e.g., personalized content) and accompanied by explicit consent and a clear privacy policy, it could be intentional. However, the detected-on-load behavior and lack of visible user consent controls make this a high-priority concern.
Suggested Fix
Move all AI/LLM network requests behind explicit user interaction or a clear consent prompt. Lazily load AI calls, scrub any PII before sending, and implement a privacy policy notice. Consider routing through a secure backend/proxy and using environment-configured endpoints with strict data-handling rules. Audit and minimize data sent to AI services.
Why Fix
Defers potentially sensitive data transmissions, improves performance, and aligns with user privacy expectations and data governance requirements.
Route To
Frontend Engineer / Privacy Engineer
Page
Tester
Jason · GenAI Code Analyzer
Technical Evidence
Console:
⚠️ AI/LLM ENDPOINT DETECTEDNetwork:
N/A (AI endpoint URL not explicitly shown in the console; the detection is logged without a visible URL in the provided data)