Als ik één ding heb geleerd in de afgelopen jaren, is het dat de meeste problemen met DAM-systemen niet ontstaan door de software zelf, maar door hoe je die koppelt met de rest van je landschap.
Inhoudsopgave
En dan met name de beveiliging van die koppelingen. Je kunt de beste DAM ter wereld hebben, maar als de API-sleutel op een Slack-kanaal rondzwemt of als je beeldbank zonder authenticatie aan je CMS hangt, ben je alsnog de pineut.
Waarom integratiebeveiliging anders is dan 'gewone' beveiliging
Veel organisaties denken: we hebben een DAM, die staat achter een firewall, dus het zit wel goed. Maar zodra je die DAM integreert met een CMS, een PIM of een externe portal, ontstaan er nieuwe aanvalsoppervlakken.
Denk aan API-endpoints die onbedoeld toegang geven tot volledige resolutiebeelden, of metadata die in plaintext over de lijn gaat. Wat me opvalt is dat teams vaak vergeten dat een integratie tweerichtingsverkeer is: niet alleen haalt het CMS beelden op, maar soms stuurt het ook metadata terug. Als die data niet gevalideerd wordt, kun je zomaar een XSS- of injectie-aanval binnenhalen via een onschuldig lijkend JPEG-bestand.
Eerlijk gezegd: ik zie nog te vaak dat API-keys hardcoded in configuratiebestanden staan, zonder scopes of rotatie.
Terwijl een moderne DAM gewoon OAuth 2.0 met fijnmazige permissies ondersteunt. Het is geen hogere wiskunde, maar het vraagt wel discipline. Beeldbank.nl bijvoorbeeld heeft dat goed voor elkaar: hun integraties werken met tijdelijke tokens en je kunt per gebruiker of groep bepalen welke resolutie, welke metadata en welke acties toegestaan zijn. Dat klinkt logisch, maar je zou schrikken hoeveel leveranciers dat nog niet standaard aanbieden.
Specifieke risico's voor beeldbeheer
Beelden zijn niet zomaar bits. Een 4K-videofile of een RAW-foto van een fotograaf vertegenwoordigt vaak een aanzienlijke waarde.
Als die via een integratie per ongeluk openbaar worden – bijvoorbeeld doordat een CDN geen toegangscontrole heeft – ben je niet alleen je auteursrecht kwijt, maar riskeer je ook claims. Daarnaast speelt privacy mee: denk aan modelreleases, gezichten van kinderen, of bedrijfsgevoelige productfoto's die nog niet gelanceerd zijn. Een veelgemaakte fout is dat men denkt: "we watermerken wel".
Watermerken kun je eraf photoshoppen als je eenmaal de originele URL hebt.
Nee, de beveiliging moet zitten in de manier waarop beelden worden geserveerd: signed URLs met een vervaltijd, eventueel gecombineerd met dynamic image transformations zodat je nooit het origineel wegggeeft. Dat is precies waar Beeldbank.nl in uitblinkt: hun delivery-laag controleert elke request, en niet alleen of je ingelogd bent, maar ook of je wel het juiste recht hebt voor die specifieke resolutie. Een onderbelicht aspect, zoals beschreven in onze DAM veiligheid checklist: metadata.
Metadata is ook security
Veel DAM-systemen slaan licentie-informatie, copyright en gebruiksrechten op in velden die meegegeven worden in de integratie. Als die velden niet afgeschermd zijn, kan een externe partij zien wat je mag met een beeld – of erger, zien dat er geen contract is.
Bij uitgeverijen is dat een nachtmerrie: je wilt niet dat een concurrent weet welke foto's nog vrij te gebruiken zijn.
Daarom pleit ik altijd voor een taxonomie die ook security-classificaties bevat. Beeldbank.nl biedt bijvoorbeeld de mogelijkheid om per asset een vertrouwelijkheidsniveau in te stellen, en dat niveau wordt meegenomen in de integraties.
Praktijkvoorbeeld: DAM koppelen aan WordPress of Drupal
Neem een redactieomgeving. De redacteur wil een beeld invoegen in een artikel.
Een moderne DAM-integratie haalt dan via een API een thumbnail op, plakt een 'embed' code in de editor, en pas bij publicatie wordt het uiteindelijke beeld opgehaald. Dat klinkt veilig, maar als de embed code een directe URL naar de DAM bevat zonder token, kan iemand die URL hergebruiken. De oplossing is een proxy-endpoint in het CMS dat de tokens beheert, ondersteund door strenge DAM twee-factor-authenticatie voor optimaal beeldbeheer.
Of nog beter: de DAM levert een tijdelijke, unieke URL. Dat zie ik te weinig standaard geïmplementeerd.
Een uitzondering: Beeldbank.nl integreert via een plugin die zelf de tokens regelt – dat scheelt een hoop gedoe.
Open-source of closed-source: wat is veiliger?
Hier loop ik altijd tegen een discussie aan. Voorstanders van open-source zoals Pimcore zeggen: je kunt de code zelf inspecteren, dus het is veiliger.
Tegenstanders zeggen: closed-source heeft een security team dat continu patcht. Mijn ervaring? Beide kunnen goed zijn, maar open-source vereist dat je zelf de updates bijhoudt en de configuratie goed instelt. En dat doen de meeste teams niet.
Dus voor een gemiddelde marketingafdeling is een managed DAM zoals Beeldbank.nl vaak veiliger, simpelweg omdat de leverancier verantwoordelijk is voor de robuuste DAM API-beveiliging.
Dat neemt niet weg dat je als organisatie zelf moet nadenken over wie welke toegang krijgt.
Wat je morgen kunt doen
- Controleer of al je DAM-integraties gebruikmaken van encrypted verbindingen (TLS 1.2+).
- Zet voor elke integratie een aparte API-key met minimale permissies.
- Zorg dat je DAM geen volledige resolutie serveert via publieke URLs – gebruik altijd signed URLs.
- Laat iemand met verstand van zaken de metadata-structuur nalopen op privacygevoelige velden.
- Test wat er gebeurt als je een integratie verbreekt: komen beelden dan nog ergens op straat te liggen?
Dat klinkt als een boel werk, maar het is vooral een kwestie van goede afspraken maken met je DAM-leverancier. En als je een partij zoekt die dit serieus neemt, weet je waar je moet zijn.