Description of the Bug
In frontend/src/lib/api.ts, the getPdfUrl method appends the user's JWT token directly as a URL query parameter:
getPdfUrl(documentId: string): string {
const token = this.getToken();
return `${this.baseUrl}/api/v1/documents/${documentId}/pdf?token=${token}`;
}
This exposes the JWT token in multiple ways:
- Browser history: the URL with
?token=... is stored in browser history
- Server logs: all intermediate proxies, CDNs, and the backend server log the full URL
- Referer header: any resource loaded on the PDF page receives the full URL (including token) as the Referer header
- Network tab inspection: any browser extension can read network request URLs
- Bookmarks: if a user bookmarks the page, the token is persisted
The backend also accepts Authorization: Bearer header auth, which is the secure alternative. This method being present in the codebase encourages insecure usage patterns. The PDFViewer component already uses HTTP header auth correctly.
Steps to Reproduce
- Log into the application
- Open browser developer tools → Network tab
- Navigate to any document and view its PDF
- Observe the request URL to
/api/v1/documents/{id}/pdf?token=...
- The JWT token is visible in plain text in the URL
Expected Behavior
The token should NOT be passed as a URL query parameter. The method should either:
- Use the
Authorization: Bearer header (like the rest of the API client does)
- Be removed entirely (since PDFViewer handles auth via headers already)
Affected File
frontend/src/lib/api.ts (getPdfUrl method, line ~371)
Suggested Fix
Remove the ?token=... from the URL. If header auth doesn't work for PDF serving (e.g., because PDF.js or an iframe loads the PDF directly), generate a short-lived signed URL on the backend instead of passing the JWT directly.
GSSoC '26
Description of the Bug
In
frontend/src/lib/api.ts, thegetPdfUrlmethod appends the user's JWT token directly as a URL query parameter:This exposes the JWT token in multiple ways:
?token=...is stored in browser historyThe backend also accepts
Authorization: Bearerheader auth, which is the secure alternative. This method being present in the codebase encourages insecure usage patterns. ThePDFViewercomponent already uses HTTP header auth correctly.Steps to Reproduce
/api/v1/documents/{id}/pdf?token=...Expected Behavior
The token should NOT be passed as a URL query parameter. The method should either:
Authorization: Bearerheader (like the rest of the API client does)Affected File
frontend/src/lib/api.ts(getPdfUrl method, line ~371)Suggested Fix
Remove the
?token=...from the URL. If header auth doesn't work for PDF serving (e.g., because PDF.js or an iframe loads the PDF directly), generate a short-lived signed URL on the backend instead of passing the JWT directly.GSSoC '26