Doconut‑visare blir en del av din applikations säkerhetsgräns så snart den visar kontrakt, fakturor, ingenjörsritningar eller kundregister. Doconut tillhandahåller visningslagret; den omgivande applikationen måste fortfarande besluta vem som får öppna en fil, var källan lagras, hur länge härledd data är tillgänglig och vad som registreras för utredning.

Ett skyddat dokument omgiven av lager av åtkomstkontroller och en revisionsspårning

Doconuts artikel om säkra dokumentvisningspraxis beskriver server‑sidig rendering som ett lager i en djupgående försvarsdesign. Denna artikel fokuserar därför på applikationens ansvar kring Doconut och hänvisar till produktens underhållna dokumentation för implementationsdetaljer.

Börja med en hotmodell

“Privat” och “säker” är inte konfigurationer. Definiera de händelser du behöver förhindra eller upptäcka innan du väljer kontroller.

Risk	Exempel	Applikationskontroll
Obehörig åtkomst	En användare ändrar ett dokumentidentifierare i URL‑en	Objekt‑nivå auktorisation på varje begäran
Hyresgäst‑överskridning	En giltig användare begär en annan kunds fil	Hyresgäst‑omfång inkluderat i auktorisationsbeslutet
Källexponering	En lagringsväg eller originalfil returneras direkt	Server‑styrd uppslagning och renderingsflöde
Föråldrad åtkomst	En länk förblir användbar efter att en roll eller ett ärende ändrats	Kort sessionstid plus återvalidering av auktorisation
Överdrivet bevarande	Tillfälliga in‑ eller utdata samlas	Explcita livscykeljobb med observerbara resultat
Känslig loggning	Token eller fillokaler visas i loggar	Strukturerad maskering och endast identifierings‑telemetri

Prioritera risker utifrån dokumenten och användarna i ditt system. Ett offentligt broschyrbibliotek och en juridisk bevisportal bör inte dela samma policy bara för att de använder samma visare.

Doconuts juridiskt dokumentgranskningsfall är en användbar referens för produktens roll i autentiserade ärende‑, kontrakt‑, bevis‑ och efterlevnadsarbetsflöden. Det understryker också den arkitektoniska gränsen: behörigheter, lagring, kundregister och affärsregler förblir nära värdapplikationen.

Auktorisera innan dokumentet öppnas

Utför autentisering och objekt‑nivå auktorisation innan du öppnar dokumentet med Doconut. Den officiella .NET 6‑ eller högre installationsguiden visar hur visaren konfigureras och hur ett server‑sidigt dokument öppnas; placera din applikations identitet, hyresgäst och dokument‑behörighetskontroller före detta produktsteg.

Upprepa samma auktorisationsregel för varje relaterad operation som din applikation exponerar, inklusive sidor, miniatyrbilder, sök, anteckningar, konvertering, nedladdning och utskrift. Att dölja en knapp skyddar inte den underliggande begäran.

Undvik att acceptera en filsystävssökväg, lagringsnyckel eller fjärr‑URL direkt från webbläsaren. Lös upp ett applikations‑ägt dokument‑ID till dess lagringsplats på servern, och bekräfta sedan att det upplösta objektet tillhör den auktoriserade hyresgästen och arbetsflödet.

Separera visaren från lagringspolicy

Visaren bör inte definiera din bevarandetid. Dokumentera varje lagringsklass och ägare:

Källdokument — styrt av din primära innehålls‑ eller registerpolicy.
Tillfälliga arbetsfiler — skapas för bearbetning och tas bort av ett schemalagt, observerbart livscykeljobb.
Renderade sidor eller cache — begränsade till den minsta användbara livslängden och skyddade som källan.
Export‑ och utskriftsklara filer — skapas endast när användaren har motsvarande behörighet.
Loggar och revisionshändelser — innehåller identifierare och resultat, inte dokumentinnehåll eller autentiseringsuppgifter.

Kryptering i transit och i vila beror på din webbserver, lagringsleverantör, nyckelhantering och distributionsinställningar. Verifiera dessa kontroller i den faktiska miljön; anta dem inte bara för att ett visarbibliotek finns.

Använd kortlivade referenser med försiktighet

En kortlivad referens kan minska tiden för återuppspelning, men den ersätter inte auktorisation. Om din design använder en signerad rutt eller session‑token:

Bind den till ett dokument och avsedd operation.
Ge den en snäv livstid baserad på arbetsflödet.
Undvik att placera känsliga påståenden eller lagringsplatser i klartext.
Återvalidera auktorisation för privilegierade operationer.
Definiera vad återkallelse betyder före den naturliga utgångstiden.
Håll token utanför analyser, refererare, undantagsmeddelanden och skärmdumpar.

När en webbläsarsession löper ut, visa ett neutralt meddelande och erbjud ett säkert sätt att autentisera igen. Avslöja inte om en annan hyresgäst äger dokumentet.

Förstå vad klient‑sidiga kontroller kan och inte kan göra

Att ta bort nedladdnings‑ eller utskriftskontroller kan förbättra arbetsflödet, men det är ingen konfidentialitetsgaranti. En användare som kan se innehållet kan fortfarande fånga skärmen, fotografera den eller använda webbläsarfunktioner utanför visaren.

Behandla klient‑sidiga begränsningar som användbarhets‑ och avskräckningsåtgärder. Starkare kontroller kommer från att hålla källfiler bakom servern, tillämpa auktorisation på varje relaterad begäran, begränsa export och använda synliga vattenmärken när din policy kräver det.

Gör inte produktfunktioner till efterlevnadskrav

Regulatorisk efterlevnad beror på syfte, datakategorier, laglig grund, avtal, regional bearbetning, bevarande, incidentrespons och organisatoriska rutiner. En visare kan stödja en efterlevnadsdesign, men den gör inte en applikation efterlevande i sig.

För en GDPR‑bedömning, dokumentera åtminstone:

Var käll‑ och härledda filer bearbetas och lagras
Vem som agerar som personuppgiftsansvarig och personuppgiftsbiträde för varje tjänst
Vilka underbiträden och överföringar som är involverade
Hur raderingsförfrågningar når varje lagringsklass och backup‑policy
Vilka händelser som loggas och hur länge loggarna är tillgängliga
Hur åtkomstgranskningar och incidentrespons utförs

Låt integritets‑ och juridiska intressenter validera dessa beslut för din utrullning.

Lägg till säkerhetsrubriker och cache‑regler

För autentiserade förhandsgranskningsrutter, utvärdera en restriktiv Content Security Policy, ram‑policy, MIME‑sniff‑skydd och en referer‑policy. Om förhandsgranskningen visas i en iframe, specificera de avsedda föräldradomänerna explicit.

Välj cache‑rubriker enligt känsligheten och renderingsrutten. no-store kan vara lämpligt för vissa svar, men det kan påverka prestanda och raderar inte innehåll som redan fångats någon annanstans. Testa webbläsar‑, proxy‑ och CDN‑beteende snarare än att förlita dig på en enskild rubrik.

Logga beslut, inte hemligheter

Ett användbart revisionshändelse kan innehålla:

Användar‑ och hyresgästidentifierare
Dokumentidentifierare
Begärd operation
Auktorisationsresultat
Tidsstämpel och korrelations‑ID
Bevarande‑ eller rensningsresultat

Undvik att logga råa token, frågesträngar, lagrings‑URL:er, dokumentnamn som innehåller personuppgifter eller extraherad text. Skydda revisionsloggar från ändring och begränsa åtkomst till de team som behöver dem.

Verifiera hela flödet

Säkerhetstestning bör inkludera negativa fall:

Ändra dokument‑ID medan du förblir autentiserad.
Återanvänd en förhandsgransknings‑URL från en annan användare eller hyresgäst.
Anropa sida‑, miniatyr‑, utskrifts‑ och export‑endpunkter direkt.
Låt sessionen gå ut under en lång förhandsgranskning.
Ta bort en användares behörighet medan ett dokument är öppet.
Skicka ej‑stödd, för stor, skadad eller lösenordsskyddad indata.
Bekräfta att rensningsjobb tar bort berättigad data och rapporterar fel.
Inspektera loggar, analyser och fel‑sidor för känsliga värden.

Automatisera de stabila fallen och behåll en manuell granskning för lagringskonfiguration, webbläsarpolicy och visar‑versionsändringar.

Slutsats

En säkerhetsmedveten integration har tydligt ägarskap. Doconut tillhandahåller dokument‑visningskapaciteten som beskrivs i dess officiella dokumentation; din applikation levererar autentisering, auktorisation, lagringskontroller, bevarande, övervakning och incidentrespons. Att hålla dessa ansvar tydligt ger starkare kontroller och ärligare integritetsanspråk.