Leer hoe je een permissiebewuste globale zoekfunctie ontwerpt met snelle indexering en strikte per‑record toegangscontroles, zodat gebruikers snel resultaten krijgen zonder datalekken.
Globale zoekfunctie betekent meestal één zoekvak dat de hele app doorzoekt: klanten, tickets, facturen, documenten, gebruikers en wat mensen verder nog gebruiken. Het voedt vaak autocomplete en een snelle resultatenpagina zodat gebruikers direct naar een record kunnen springen.
Een lek ontstaat wanneer zoekresultaten iets teruggeven dat de gebruiker niet mag weten dat het bestaat. Zelfs als ze het record niet kunnen openen, kan één regel—een titel, iemands naam, een tag of een gemarkeerde snippet—gevoelige informatie prijsgeven.
Zoeken voelt vaak als "alleen lezen", dus teams onderschatten het risico. Maar het kan informatie prijsgeven via resultaat‑titels en previews, autocomplete‑suggesties, totaal‑aantallen, facets zoals "Customers (5)", en zelfs via timingverschillen (snel voor sommige termen, trager voor andere).
Dit probleem verschijnt meestal later, niet op dag één. In het begin publiceren teams zoekfunctie wanneer er nog maar één rol is, of wanneer iedereen alles kan zien in een testdatabase. Naarmate het product groeit voeg je rollen toe (support vs sales, managers vs agents) en functies zoals gedeelde inboxen, privé‑notities, beperkte klanten en "only my accounts." Als zoeken nog op oude aannames leunt, begint het aanwijzingen te geven die cross‑team of cross‑customer zijn.
Een veelvoorkomend faalpatroon is alles indexeren voor snelheid en vervolgens proberen resultaten in de app te filteren nadat de zoekopdracht al heeft gelopen. Dat is te laat. De zoekmachine heeft al bepaald wat matcht en kan beperkte records blootgeven via suggesties, counts of gedeeltelijke velden.
Stel je een supportagent voor die alleen tickets voor hun toegewezen klanten mag zien. Ze typen "Acme" en autocomplete laat "Acme - Legal escalation" of "Acme breach notification" zien. Zelfs als klikken faalt met "access denied", is de titel op zich al een datalek.
Het doel van een permissie‑bewuste globale zoekfunctie is simpel gezegd en moeilijk te implementeren: geef snelle, relevante resultaten terwijl je precies dezelfde toegangsregels afdwingt die gelden bij het openen van elk record. Elke query moet zich gedragen alsof de gebruiker alleen zijn slice van de data kan zien, en de UI moet vermijden dat er extra aanwijzingen (zoals counts) buiten die slice lekken.
Globale zoekfunctie voelt eenvoudig omdat gebruikers woorden typen en antwoorden verwachten. Onder de motorkap creëer je echter een nieuw aanvalsgebied voor datalekken. Voordat je een index of databasefunctie kiest, wees duidelijk over twee dingen: welke objecten je doorzoekt (entiteiten) en welke delen van die objecten gevoelig zijn.
Een entiteit is elk record dat iemand snel wil vinden. In de meeste zakelijke apps zijn dat klanten, supporttickets, facturen, orders en bestanden (of bestandmetadata). Het kan ook personenrecords bevatten (gebruikers, agents), interne notities en systeemobjecten zoals integraties of API‑sleutels. Als het een naam, ID of status heeft die iemand kan typen, belandt het vaak in globale zoekfunctie.
Per‑tabel regels zijn grof: of je hebt toegang tot de hele tabel, of niet. Voorbeeld: alleen Finance mag de facturenpagina openen. Dat is makkelijk te begrijpen, maar het faalt als verschillende mensen verschillende rijen in dezelfde tabel moeten zien.
Per‑record regels beslissen zichtbaarheid rij‑voor‑rij. Voorbeeld: een supportagent kan tickets zien die aan hun team zijn toegewezen, terwijl een manager alle tickets in hun regio kan zien. Een veelvoorkomende regel is tenant‑eigendom: in een multi‑tenant‑app mag een gebruiker alleen records zien waar customer_id = their_customer_id.
Juist deze per‑record regels zijn waar zoeken meestal lekt. Als je index een hit teruggeeft voordat je rijtoegang controleert, heb je al onthuld dat iets bestaat.
"Toegang hebben" is zelden een simpele ja/nee schakelaar. Het combineert vaak eigendom (door mij gemaakt, aan mij toegewezen), lidmaatschap (mijn team, mijn afdeling, mijn rol), scope (mijn regio, business unit, project), recordstatus (gepubliceerd, niet gearchiveerd) en uitzonderingen (VIP‑klanten, juridische blokkades, beperkte tags).
Schrijf deze regels eerst in platte taal neer. Later zet je die om in een datamodel plus server‑side checks.
Zoekresultaten bevatten vaak een preview‑snippet, en snippets kunnen gevoelige data lekken zelfs als de gebruiker het record niet kan openen.
Een veilig default is alleen minimale, niet‑gevoelige velden te tonen totdat toegang is bevestigd: een weergavenaam of titel (soms gemaskeerd), een korte identifier (zoals een ordernummer), een hoogover status (Open, Paid, Shipped), een datum (aangemaakt of bijgewerkt) en een generiek entiteitslabel (Ticket, Invoice).
Concreet voorbeeld: als iemand zoekt op "Acme merger" en er bestaat een beperkt ticket, dan is "Ticket: Acme merger draft - Legal" al een lek. Een veiliger resultaat is "Ticket: Restricted" zonder snippet, of helemaal geen resultaat, afhankelijk van je beleid.
Deze definities van tevoren goed vastleggen maakt latere beslissingen eenvoudiger: wat je indexeert, hoe je filtert en wat je bereid bent prijs te geven.
Mensen gebruiken globale zoekfunctie als ze haast hebben. Als het langer dan een seconde duurt, verliezen ze er vertrouwen in en gaan ze terug naar handmatig filteren. Maar snelheid is maar de helft van het verhaal. Een snelle zoekfunctie die zelfs één recordtitel, klantnaam of ticketonderwerp lekt is slechter dan geen zoekfunctie.
De kernregel is ononderhandelbaar: dwing permissies af op query‑tijd, niet alleen in de UI. Een rij verbergen nadat je hem hebt opgehaald is al te laat, omdat het systeem al data heeft aangeraakt die het niet had mogen teruggeven.
Hetzelfde geldt voor alles rondom zoeken, niet alleen de uiteindelijke resultatenlijst. Suggesties, top hits, counts en zelfs "geen resultaten"‑gedrag kunnen informatie lekken. Autocomplete die "Acme Renewal Contract" toont aan iemand die het niet mag openen is een lek. Een facet dat zegt "12 matching invoices" is een lek als de gebruiker er maar 3 mag zien. Zelfs timing kan lekken als beperkte matches de query trager maken.
Een veilige globale zoekfunctie heeft vier eigenschappen:
Verander je mindset: behandel zoeken als een data‑API, niet als een UI‑feature. Dat betekent dat dezelfde toegangsregels die je toepast op lijstpagina's ook moeten gelden voor indexopbouw, query‑uitvoering en alle gerelateerde endpoints (autocomplete, recente zoekopdrachten, populaire queries).
Een zoekvak is gemakkelijk te bouwen. Een permissie‑bewuste globale zoekfunctie is lastiger omdat de index direct resultaten wil teruggeven terwijl je app nooit records mag onthullen die de gebruiker niet mag zien, zelfs niet indirect.
Hieronder drie patronen die teams vaak gebruiken. De juiste keuze hangt af van hoe complex je toegangsregels zijn en hoeveel risico je kunt tolereren.
Benadering A: indexeer alleen "veilige" velden en haal pas na permissiecheck de rest op.
Je bewaart een minimaal document in de zoekindex, bijvoorbeeld een ID plus een niet‑gevoelig label dat veilig is om aan iedereen in de zoek‑UI te tonen. Als een gebruiker op een resultaat klikt, laadt je app het volledige record uit de primaire database en past daar de echte permissieregels toe.
Dit verkleint het lekrisico, maar kan de zoekervaring dun maken omdat gebruikers weinig context krijgen. Het vereist ook zorgvuldige woordkeuze in de UI zodat een "veilig" label geen geheimen prijsgeeft.
Benadering B: sla permissie‑attributen in de index op en filter daar.
Je neemt velden zoals tenant_id, team_id, owner_id, rolflags of project_id op in elk geïndexeerd document. Elke query voegt filters toe die passen bij het huidige bereik van de gebruiker.
Dit levert snelle, rijke resultaten en goede autocomplete, maar het werkt alleen wanneer toegangsregels als filters te vangen zijn. Als permissies afhangen van complexe logica (bijvoorbeeld "assigned OR on‑call deze week OR onderdeel van een incident"), wordt het lastig om het correct te houden.
Benadering C: hybride. Groffe filter in de index, definitieve check in de database.
Je filtert in de index op stabiele, brede attributen (tenant, workspace, klant) en hercontroleert permissies op de kleine set kandidaat‑IDs in de primaire database voordat je iets teruggeeft.
Dit is vaak het veiligste pad voor echte apps: de index blijft snel en de database blijft de enige bron van waarheid.
Kies A wanneer je de eenvoudigste setup wilt en kunt leven met minimale snippets. Kies B wanneer je duidelijke, grotendeels statische scopes hebt (multi‑tenant, teamgebaseerde toegang) en je extreem snelle autocomplete nodig hebt. Kies C wanneer je veel rollen, uitzonderingen of record‑specifieke regels hebt die vaak veranderen. Voor hoog‑risico data (HR, finance, medisch) verdient C de voorkeur omdat "bijna correct" onacceptabel is.
Begin met je toegangsregels op te schrijven zoals je het aan een nieuwe collega zou uitleggen. Vermijd "admin kan alles" tenzij dat echt waar is. Omschrijf de redenen: "Supportagents kunnen tickets van hun tenant zien. Teamleads kunnen ook tickets van hun org‑unit zien. Alleen de ticketeigenaar en toegewezen agent kunnen privé‑notities zien." Als je niet kunt zeggen waarom iemand een record kan zien, wordt het moeilijk om het veilig te coderen.
Kies vervolgens een stabiele identifier en definieer een minimaal zoekdocument. De index zou geen volledige kopie van je databaserecord moeten zijn. Houd alleen wat nodig is om te vinden en weer te geven in de resultatenlijst, zoals titel, status en eventueel een korte, niet‑gevoelige snippet. Zet gevoelige velden achter een tweede fetch die ook permissies controleert.
Bepaal daarna welke permissiesignalen je snel kunt filteren. Dat zijn attributen die toegang begrenzen en op elk geïndexeerd document opgeslagen kunnen worden, zoals tenant_id, org_unit_id en een klein aantal scopeflags. Het doel is dat elke query filters kan toepassen vóór het teruggeven van resultaten, inclusief autocomplete.
Een praktisch workflowvoorbeeld:
Gedeelde items en uitzonderingen zijn waar ontwerpen vaak breken. Als een ticket over teams heen gedeeld kan worden, voeg dan niet zomaar een boolean toe. Gebruik expliciete grants die door filters gecontroleerd kunnen worden. Als de allowlist groot is, geef de voorkeur aan groepsgebaseerde grants in plaats van individuele gebruikers.
Een veilige zoekervaring hangt van één saaie maar cruciale zaak af: de index moet de werkelijkheid weerspiegelen. Als een record wordt gemaakt, gewijzigd, verwijderd of als permissies veranderen, moeten zoekresultaten snel en voorspelbaar meebewegen.
Behandel indexering als onderdeel van je datalevenscyclus. Een nuttig mentaal model is: elke keer dat de bron van waarheid verandert, emit je een event en de indexer reageert daarop.
Veelgebruikte benaderingen zijn database‑triggers, applicatie‑events of een jobqueue. Het belangrijkste is dat events niet verloren gaan. Als je app het record kan opslaan maar falen in indexeren, krijg je verwarrend gedrag zoals "Ik weet dat het bestaat maar zoeken kan het niet vinden."
Veel lekken ontstaan wanneer content correct wordt bijgewerkt, maar toegangsmetadata niet. Permissiewijzigingen komen van rolupdates, team‑wissels, eigendomsoverdrachten, klantherassignments of een ticket dat in een ander geval wordt samengevoegd.
Maak permissiewijzigingen eersteklas events. Als je permissie‑bewuste zoekfunctie leunt op tenant‑ of teamfilters, zorg dan dat geïndexeerde documenten de velden bevatten die nodig zijn om dat af te dwingen (tenant_id, team_id, owner_id, allowed_role_ids). Als die velden veranderen, reindex.
Het lastige is de blast radius. Een rolverandering kan duizenden records beïnvloeden. Plan een bulk‑reindexpad met voortgang, retries en een manier om te pauzeren.
Zelfs met goede events is er een venster waarin zoeken achterloopt. Bepaal wat gebruikers zouden moeten zien in de eerste seconden na een wijziging.
Twee regels helpen:
Zoeken is voor ontdekking, maar details bekijken is waar lekken echt pijn doen. Doe een tweede permissiecheck bij het lezen voordat je gevoelige velden toont. Als een resultaat door een stalen index heen glipt, moet de detailpagina nog steeds toegang blokkeren.
Een goed patroon: toon minimale snippets in zoekresultaten en check permissies opnieuw wanneer de gebruiker het record opent (of een preview uitklapt). Als de check faalt, toon een duidelijke melding en verwijder het item uit de zichtbare set bij de volgende refresh.
Zoeken kan data lekken zelfs wanneer je "open record"‑pagina goed is vergrendeld. Een gebruiker hoeft nooit op een resultaat te klikken om namen, klant‑IDs of de omvang van een verborgen project te leren. Permissie‑bewuste globale zoekfunctie moet niet alleen documenten beschermen, maar ook aanwijzingen over documenten.
Autocomplete is een veelvoorkomende bron van lekken. Suggesties draaien vaak op een snelle prefix‑lookup die volledige permissiechecks overslaat. De UI lijkt onschuldig, maar één getypte letter kan een klantnaam of iemands e‑mail onthullen. Autocomplete moet dezelfde toegangfilter draaien als volledige zoekopdrachten, of gebouwd zijn uit een vooraf‑gefilterde suggestieset (bijv. per‑tenant en per‑rol).
Facetcounts en "Ongeveer 1.243 resultaten"‑banners zijn een stille lekkagebron. Aantallen kunnen bevestigen dat iets bestaat, zelfs als je de records verbergt. Als je counts niet veilig kunt berekenen onder dezelfde toegangsregels, toon dan minder details of laat counts weg.
Caching is ook een veelvoorkomende boosdoener. Gedeelde caches over gebruikers, rollen of tenants kunnen "resultaat‑geesten" creëren, waarbij de ene gebruiker resultaten ziet die voor iemand anders zijn gemaakt. Dit kan gebeuren met edge caches, applicatiecaches en in‑memory caches binnen een zoekservice.
Leak‑valstrikken om vroeg te controleren:
Let ook op te brede filters. "Filter by tenant only" is de klassieke multi‑tenant fout, maar het gebeurt ook binnen één tenant: filteren op "department" wanneer toegang rij‑voor‑rij moet. Voorbeeld: een supportagent zoekt "refund" en krijgt resultaten over alle klanten in de tenant, inclusief VIP‑accounts die alleen voor een kleiner team zichtbaar mogen zijn. De oplossing is simpel in principe: handhaaf rij‑niveau regels in elke query‑pad (search, autocomplete, facets, exports), niet alleen in de recordweergave.
Veel ontwerpen richten zich op "wie mag wat zien", maar leaks ontstaan ook via de randen: lege staten, timing en kleine hints in de UI. Permissie‑bewuste zoekfunctie moet veilig zijn, ook wanneer er niets teruggegeven wordt.
Een eenvoudig lek is bevestiging door afwezigheid. Als een ongeautoriseerde gebruiker zoekt op een specifieke klantnaam, ticket‑ID of e‑mail en een speciale melding krijgt zoals "No access" of "You don't have permission", dan heb je bevestigd dat het record bestaat. Behandel "geen resultaten" als de standaarduitkomst voor zowel "bestaat niet" als "bestaat maar niet toegestaan". Houd responstijd en tekst consistent zodat mensen niet op basis van snelheid kunnen raden.
Autocomplete en search‑as‑you‑type zijn plekken waar privacy glipt. Gedeeltelijke matches op e‑mails, telefoonnummers en overheids‑ of klant‑IDs kunnen meer blootgeven dan je bedoelt. Bepaal vooraf hoe deze velden zich gedragen.
Een praktische set regels:
Als het tonen van zelfs één teken iemand helpt data te raden, behandel dat veld als gevoelig.
Zoekendpoints zijn ideaal voor enumeratieaanvallen: veel queries proberen om te mappen wat er bestaat. Voeg rate limits en anomaliedetectie toe, maar wees voorzichtig met wat je opslaat. Logs met ruwe queries kunnen een tweede datalek worden.
Houd het simpel: rate limit per gebruiker, per IP en per tenant; log aantallen, timing en grove patronen (niet de volledige querytekst); waarschuw bij herhaalde "near‑miss" queries (zoals opeenvolgende ID's); en blokkeer of verhoog verificatie na herhaalde mislukte pogingen.
Maak je fouten saai. Gebruik hetzelfde bericht en lege staat voor "geen resultaten", "niet toegestaan" en "ongeldige filters." Hoe minder je zoek‑UI zegt, hoe minder het per ongeluk kan onthullen.
Een supportagent, Maya, werkt in een team dat drie klantaccounts behandelt. Ze heeft één zoekvak in de appheader. Het product heeft een globale index over tickets, contacten en bedrijven, maar elk resultaat moet toegangsregels respecteren.
Maya typt "Alic" omdat een beller zei dat hun naam Alice is. Autocomplete toont een paar suggesties. Ze klikt "Alice Nguyen - Ticket: Password reset." Voordat iets opent, hercontroleert de app toegang voor dat record. Als het ticket nog steeds aan haar team is toegewezen en haar rol het toestaat, krijgt ze de ticketpagina te zien.
Wat Maya bij elke stap ziet:
Vergelijk dat met Leo, een nieuwe agent in opleiding. Zijn rol mag alleen tickets zien die als "Public to Support" zijn gemarkeerd en alleen voor één klant. Leo typt dezelfde query, "Alic." Hij ziet minder suggesties en geen enkele hint van de ontbrekende items. Er is geen "5 results" count die andere matches bevestigt. De UI toont gewoon wat hij kan openen.
Later wijst een manager "Alice Nguyen - Password reset" van Maya's team toe aan een gespecialiseerd escalatieteam. Binnen een korte periode (meestal seconden tot een paar minuten, afhankelijk van je sync‑aanpak) stopt Maya's zoekfunctie met het teruggeven van dat ticket. Als ze de detailpagina open heeft en ververst, hercontroleert de app permissies en verdwijnt het ticket.
Dat is het gewenste gedrag: snel typen en snelle resultaten, zonder dat er datageur (counts, snippets of stalen indexitems) lekt.
Permissie‑bewuste globale zoekfunctie is pas "klaar" wanneer de saaie randen veilig zijn. Veel lekken gebeuren op plekken die onschuldig lijken: autocomplete, resultaten‑aantallen en exports.
Voordat je live gaat, loop deze checks door met echte data, niet met samples:
Maak een kleine rolmatrix (rollen × entiteiten) en een dataset met opzettelijk lastige cases: gedeelde records, recent ingetrokken toegang en lookalikes over tenants heen.
Test in drie rondes: (1) rolmatrix‑tests waarbij je verifieert dat geweigerde records nooit verschijnen in resultaten, suggesties, counts of exports; (2) "probeer het kapot te maken"‑tests waarbij je ID's plakt, zoekt op e‑mail of telefoon en gedeeltelijke matches probeert die niets zouden mogen teruggeven; (3) timing‑ en cache‑tests waarbij je permissies verandert en bevestigt dat resultaten snel bijwerken zonder stalen suggesties.
Operationeel: plan voor de dag waarop zoekresultaten "vreemd lijken." Log de querycontext (gebruiker, rol, tenant) en de toegepaste permissiefilters, maar sla geen ruwe gevoelige querystrings of snippets op. Voor veilig debuggen bouw een admin‑alleen tool die kan uitleggen waarom een record matchte en waarom het werd toegestaan.
Als je op AppMaster (appmaster.io) bouwt, is een praktische aanpak om zoeken als een server‑side flow te houden: modelleer entiteiten en relaties in de Data Designer, handhaaf toegangsregels in Business Processes en hergebruik diezelfde permissiecheck voor autocomplete, resultatenlijst en exports zodat er maar één plek is om het goed te doen.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
