Every user can read every other user's applications

An Application row contains a user's employer names, the roles they're interviewing for, and freeform private notes -- the kind of information someone very much does not want their current employer, a recruiter, or a stranger to see. Right now, any authenticated user can list every other user's applications just by calling GET /api/applications/ as themselves -- company names, roles, and notes included. This is a confidentiality breach across every account on the system, the kind of finding that turns into a mandatory disclosure, a trust-destroying incident for a tool whose entire premise is "track your confidential job search privately," and, per the project's own README (which documents user isolation as a core guarantee), a direct contradiction of a promise already made to users.

get_queryset() returns Application.objects.all().select_related("user").prefetch_related("status_changes") -- every application belonging to every user, not just the one making the request. The comment directly above the method still describes the intended (and previously actual) behavior of filtering by the requesting user before any lookup by id, which is exactly what makes this easy to miss on a quick read: the code "looks right" if you only read the explanation above it.

python manage.py shell -c " from django.contrib.auth import get_user_model from applications.models import Application from rest_framework.test import APIClient User = get_user_model() alice = User.objects.create_user(username='alice6', password='pw-alice6-123') bob = User.objects.create_user(username='bob6', password='pw-bob6-12345') Application.objects.create(user=alice, company='Acme', role='Engineer', notes='confidential') c = APIClient(); c.force_authenticate(user=bob) print('list count (should be 0):', c.get('/api/applications/').data['count']) "

-> list count (should be 0): 1 <-- bob sees alice's application

This is the exact scenario applications/permissions.py's IsOwner docstring names as a hypothetical: a queryset regression that removes the real defense, leaving only the weaker object-level backstop, which changes the error code (403 instead of 404) but does nothing about the list endpoint at all, since IsOwner.has_object_permission is only ever consulted for detail-route actions (retrieve/update/partial_update/destroy/timeline/status), never for list.

Compare the current get_queryset() against the comment directly above it and against README.md's "Ownership" section, which documents the exact intended behavior this method is supposed to implement.