Every Map & Location Integration Audit check

Slow map tile loads directly drive bounce rate on directory pages. On a 4G connection — the median mobile connection globally — tiles that take more than 3 seconds before showing any map content leave users staring at a blank container with no progress signal. ISO 25010:2011 performance-efficiency classifies this as a time-behavior defect. For location-based directories, the map is the primary navigation surface; a frozen or blank map during load is functionally equivalent to a broken page.

Why this severity: Medium because slow tile loading degrades perceived reliability and drives abandonment, but does not expose data or block the entire application from functioning.

When map markers do not update after a filter change, users see stale, incorrect data — listings that do not match their criteria appear pinned to the map while the sidebar list updates. This is a functional-suitability violation under ISO 25010:2011 and a concrete data-integrity failure: the map and the list are out of sync, making the product untrustworthy. Users applying category or distance filters to find, say, open restaurants or accessible venues receive misleading results that can send them to wrong locations. The defect is critical because it silently corrupts the user's decision-making.

Why this severity: Critical because desynchronized markers and filter state produce objectively wrong results that users act on, making the directory functionally unreliable for its core purpose.

Deriving coordinates from address text at render time introduces three concrete failure modes: geocoding API quota exhaustion that breaks your map entirely, incorrect marker placement when the geocoder returns an ambiguous result (CWE-20), and latency added to every page load. ISO 25010:2011 functional-suitability requires that data used for core functionality — map marker placement — is accurate and available. A listing that maps to the wrong location due to geocoding ambiguity can send users to the wrong address, which is a direct trust and safety issue for a directory product.

Why this severity: Medium because render-time geocoding degrades reliability and accuracy without being immediately obvious, but the business impact accumulates as quota costs and misplaced markers.

Rendering more than 50 individual markers simultaneously causes browser performance to degrade visibly — marker overlap makes the map unreadable, and the DOM overhead of 50+ custom elements causes frame drops on mid-range devices. ISO 25010:2011 performance-efficiency classifies this as a resource-utilization defect. For a directory with significant geographic density — urban restaurant guides, event listings, retail locators — unclustered markers make the map's core navigation function unusable at typical zoom levels.

Why this severity: Low because clustering is a performance enhancement rather than a correctness failure; the data is still present, just visually cluttered and slow.

Markers without popups force users to guess what each pin represents or drill into a separate detail page just to identify a listing, crushing map-to-detail conversion and making the directory feel broken. Users abandon flows when a tapped marker does nothing, silently loses context, or reveals only an opaque listing ID. Missing name, category, or detail link on click also breaks WCAG 2.2 SC 2.4.4 (Link Purpose) because users cannot discern where the interaction leads without surrounding context.

Why this severity: High because non-interactive markers collapse the directory's primary browse-to-detail path and strand every map visitor.

A map that requires a pointer device to navigate is inaccessible to keyboard-only users, screen reader users, and users with motor impairments — a violation of WCAG 2.2 SC 2.1.1 (Keyboard) and Section 508 2018 Refresh 502.3.3. For directories serving public-interest information (local services, healthcare providers, government facilities), keyboard inaccessibility can be a legal liability under the ADA. Users who rely on Tab navigation to cycle through markers and Enter to open detail popups receive no functional equivalent to mouse interaction if focus management is absent.

Why this severity: Medium because keyboard inaccessibility locks out a measurable user segment and creates legal exposure, but does not corrupt data or expose security vulnerabilities.

A map container without `role="application"` and a descriptive `aria-label` is opaque to screen readers. WCAG 2.2 SC 4.1.2 (Name, Role, Value) requires that all UI components expose a name and role that assistive technology can announce. Without `role="application"`, screen readers treat the map as generic content and may announce it as an unlabeled region or skip it entirely. Section 508 2018 Refresh 502.3.1 extends this requirement to federal web applications. A label like just "map" gives no context about what the map displays — users cannot determine whether it is relevant to their task before choosing to interact.

Why this severity: Medium because missing or inadequate ARIA attributes fail WCAG 2.2 SC 4.1.2 and Section 508 compliance requirements, creating legal exposure and locking out screen reader users.

A geocoding API key embedded in client-side JavaScript is visible to any user who opens DevTools — this is CWE-522 (Insufficiently Protected Credentials) and an OWASP A05:2021 (Security Misconfiguration) violation. Exposed keys can be harvested and used by third parties to run geocoding requests against your quota, resulting in unexpected billing spikes or service denial when you hit rate limits. For Google Maps API keys, quota theft has caused five-figure surprise bills. CWE-200 (Exposure of Sensitive Information) applies because the key itself represents privileged access to a paid API service.

Why this severity: Critical because an exposed geocoding API key enables quota theft and service disruption with zero authentication required — any user can extract the key from the browser.

An unrestricted map API key — one with no HTTP referrer restrictions in the provider console — is a valid, usable credential that any third party can call from any domain. CWE-732 (Incorrect Permission Assignment for Critical Resource) applies because the key grants API access without the permission boundary it should have. OWASP A05:2021 (Security Misconfiguration) covers this directly. The practical consequence is quota theft: another site embeds your Mapbox token, your tile requests and geocoding quota are consumed, and you receive the billing overage. Referrer restrictions add a cheap, server-enforced permission boundary that the provider enforces — your code cannot compensate for a missing restriction.

Why this severity: Low because referrer restriction is defense-in-depth — key theft requires an attacker who already has the key — but the consequence of unrestricted keys is measurable quota and billing exposure.

Silent geocoding failure that stores (0,0) coordinates plants listings in the Gulf of Guinea — visibly off the map for most directories, or worse, clustered with other (0,0) entries in a way that makes them appear at a real but incorrect location. CWE-754 (Improper Check for Unusual Conditions) and CWE-20 (Improper Input Validation) both apply: the application accepts invalid geocoding output without surfacing an error. ISO 25010:2011 reliability is violated because the system produces incorrect outputs without notifying the user. From a business standpoint, silent (0,0) storage corrupts the directory's data integrity and is difficult to detect and backfill at scale.

Why this severity: High because silent (0,0) storage corrupts listing data permanently without user awareness, and the defect is difficult to detect and remediate after the fact at scale.

Storing latitude and longitude with fewer than 6 decimal places introduces systematic positional error. At 4 decimal places the precision is approximately 11 meters — enough to place a marker across the street or in an adjacent building. At 2 decimal places it is roughly 1.1 kilometers, which can misplace a marker in the wrong neighborhood entirely. CWE-681 (Incorrect Conversion between Numeric Types) applies when floating-point coordinates are truncated into low-precision columns. ISO 25010:2011 functional-suitability is violated because the directory cannot reliably represent the physical location of a listing. For delivery, navigation, and accessibility use cases, 11-meter error is operationally significant.

Why this severity: Medium because coordinate precision loss silently corrupts marker placement across all listings, undermining the directory's core function without an obvious error signal.

A "near me" feature that crashes or silently fails when location permission is denied provides no usable fallback and locks out users who decline location sharing — a growing segment due to increased browser permission fatigue. ISO 25010:2011 reliability requires that systems handle expected failure conditions gracefully. From a product standpoint, permission denial is not an error state; it is a normal user choice. A crash or blank screen on denial destroys trust at exactly the moment a user is evaluating whether to engage with your directory. The feature is marked critical because it gates the primary location-based use case of the entire product.

Why this severity: Critical because geolocation permission denial is a normal, expected user action — an app crash or silent failure at this point is a primary-flow breakage that blocks location-based search entirely.

Triggering a geolocation permission prompt on page load — before any user interaction — violates GDPR Art. 5(1)(b) (purpose limitation and data minimisation) and ePrivacy Art. 5(3), which require that access to device capabilities be tied to a specific, user-initiated purpose. Browsers increasingly penalize automatic permission requests by pre-denying them, meaning an auto-triggered geolocation call trains the browser to block your site permanently. Beyond compliance, an unexpected permission dialog on load is a hostile UX pattern that signals your site does not respect user agency — a trust-damaging first impression for a directory product that depends on repeat engagement.

Why this severity: Medium because unsolicited geolocation requests violate GDPR and ePrivacy requirements and cause browsers to pre-block your site's location access, degrading the feature for all future visits.

A map that renders at coordinates (0,0) — the null island in the Gulf of Guinea — or displays a blank canvas when geolocation is unavailable is broken for every user who declines location permission, uses a browser that blocks geolocation, or accesses the site from a context where the Geolocation API is restricted. ISO 25010:2011 reliability requires graceful degradation to a usable state. For a directory product, a map centered on a relevant geographic area is the minimum functional state — users can always pan to their location manually, but they cannot use a blank or miscentered map at all.

Why this severity: Medium because a missing default center breaks the map for all users who do not grant geolocation access, which is a significant and growing segment as browser permission defaults tighten.

Bounding-box radius filtering — using `lat BETWEEN` and `lng BETWEEN` — is a rectangle, not a circle. At a 5km search radius, the corners of the bounding box extend approximately 7km from the center, meaning listings up to 40% farther than the stated radius appear in results. CWE-682 (Incorrect Calculation) applies because the distance calculation is mathematically wrong. ISO 25010:2011 functional-suitability is violated because the feature does not perform as advertised. For time-sensitive searches (finding an open restaurant, locating a nearby service), returning listings that are materially farther than the stated radius causes users to navigate to incorrect distances.

Why this severity: High because bounding-box distance calculation is mathematically incorrect and silently returns listings outside the stated radius, producing demonstrably wrong search results.

When search radius, center coordinates, and filters live only in component state, users cannot bookmark a result set, share a link to nearby listings, or reload without losing context — a direct hit to organic sharing, paid-ad landing pages, and SEO for location pages. Back-button navigation also breaks because the browser has no URL delta to restore. Encoding search state in the query string is the canonical fix and aligns with W3C URI design guidance on addressable resources.

Why this severity: High because unshareable search URLs kill viral distribution, paid-link targeting, and back-button restoration on every radius query.

A "Get Directions" button that opens an in-app directions view rather than the system maps app forces users to navigate with a less capable tool while their preferred navigation app sits unused. Schema.org Place expects machine-readable location data that enables native integrations; failing to deeplink to system maps is a missed integration with the platform's established navigation intent. For mobile users in particular, the system maps app (Apple Maps, Google Maps) has saved routes, voice guidance, and real-time traffic that an in-app view cannot replicate. Not providing a deeplink is a UX failure that increases friction at the moment of highest intent: the user is ready to physically go somewhere.

Why this severity: Low because in-app directions still function, but missing the system maps deeplink degrades navigation UX and ignores the established platform intent for directions on mobile devices.

A directions deeplink that passes an address string instead of stored coordinates requires the maps app to re-geocode the address on the user's device. This introduces latency, geocoding ambiguity (a common street name in multiple cities can resolve to the wrong location), and dependency on network availability. CWE-682 (Incorrect Calculation) applies when coordinates are derived from address at deeplink-construction time instead of retrieved from storage. Schema.org GeoCoordinates exists precisely to make precise lat/lng available for machine consumption — ignoring it in favor of address string passing defeats the purpose of storing coordinates at all.

Why this severity: Low because address-based deeplinks often work, but introduce geocoding ambiguity and unnecessary latency that can send users to the wrong destination.