Fix Shadow API Exposure in Qwik

Shadow APIs in Qwik manifest when developers treat `routeLoader$` and `routeAction$` as 'internal' server functions, forgetting they are exposed as public HTTP endpoints via Qwik's RPC mechanism. Attackers intercept the `q-data.json` or `_qwik-xhr` requests to discover these endpoints and exploit Broken Object Level Authorization (BOLA). If you aren't validating the requester's identity inside the loader itself, you've left a backdoor open to your database.

The Vulnerable Pattern

import { routeLoader$ } from '@builder.io/qwik-city';
// VULNERABLE: This creates a shadow API endpoint reachable via /?q-data.json
// An attacker can swap the ‘id’ parameter to dump any user’s profile.
export const useUserProfile = routeLoader$(async ({ params }) => {
const user = await db.table(‘users’).where(‘id’, params.id).first();
return user;
});

The Secure Implementation

Qwik's architecture blurs the line between frontend and backend. Every `routeLoader$` is effectively a GET/POST endpoint that returns JSON. To kill shadow API exposure, you must implement Zero Trust at the function level. Never trust the `params` or `query` objects without verifying them against a server-side session (stored in `sharedMap` via middleware). Use the `fail()` utility to return proper HTTP status codes instead of leaking raw exceptions or null values which can aid in service mapping by attackers.

import { routeLoader$ } from '@builder.io/qwik-city';
export const useUserProfile = routeLoader$(async ({ params, sharedMap, fail }) => {
const session = sharedMap.get(‘session’);
// 1. Authentication Check
if (!session) {
return fail(401, { message: ‘Unauthenticated’ });
}
// 2. Authorization Check (BOLA Mitigation)
// Ensure the authenticated user is only requesting their own data
if (session.user.id !== params.id) {
return fail(403, { message: ‘Forbidden: You do not own this resource’ });
}
const user = await db.table(‘users’).where(‘id’, params.id).first();
return user || fail(404, { message: ‘User not found’ });
});