Stel, je hebt een website gemaakt voor een klant. Op die website kun je inloggen met een username/password combinatie en in dit geval geeft je dat niet zoveel extra mogelijkheden, er zit achter die inlog een contactpagina voor alle ingelogde klanten, waar een lijst staat met medewerkers en directe telefoonnummers waar je ze op kunt bereiken. Dus informatie die voor alle klanten gelijkt is en alleen inzichtelijk is als je een account hebt en in kunt loggen, extra service voor echte klanten.
Maar goed, de klant wil meer. Dus op een dag komt de vraag van de klant bij jouw bedrijf binnen: kunnen jullie zorgen dat ingelogde klanten ook hun facturen kunnen bekijken? De klant heeft zelf al wat zoekwerk gedaan en levert bij je projectmanager deze URL aan: AFAS link. Want deze klant maakt gebruik van AFAS voor de administratie. Voor dit artikel is dit niet relevant, het zou ook via Exact kunnen zijn (ik neem aan dat zij ook een REST-service hebben) of een ander pakket met een API koppeling.
De projectmanager dropt deze vraag bij het team of een developer, hoe lang duurt het om de code te bouwen om dit te laten werken? De developer kijkt er naar, klikt door wat linkjes van AFAS en komt tot de conclusie dat hij/zij dit binnen een uur wel moet kunnen bouwen en geeft dit als antwoord aan de projectmanager, 1 uur. Die weet inmiddels dat developers heel vaak zaken "iets te positief inschatten" en verdubbelt dat uur naar 2 uren. En omdat de projectmanager zaken moet communiceren met de klant, een project aan moet maken en andere "administratieve handelingen" uit moet voeren, koppelt hij/zij terug aan de klant dat dit 4 uren gaat kosten.
Dan is de response van de klant even afhankelijk van "hoe de klant in de wedstrijd staat":
Scenario 1: de klant gaat akkoord met dit voorstel. Of de klant zegt: dit zijn teveel uren, ik doe het niet.
Scenario 2: de klant begint te klagen "ik heb je de URL aangeleverd, die hoef je alleen maar aan te roepen, ik heb vroeger ook nog wel wat met scripts gewerkt, dus dat moeten jullie toch wel in 1 uurtje kunnen bouwen?"
Scenario 3: de klant vindt het "te duur". Mogelijk wil de projectmanager "de opdracht scoren" en haalt wat van de uren af.
Scenario 4: een andere flow. Ik weet niet hoe of wat, maar het gaat anders dan in de voorgaande scenario's :)
Zaken lopen misschien anders, maar een klant zal niet niet zeggen: "reken er nog maar wat extra uren bij". En eigenlijk had dat wel gemoeten.... want wat missen we hier?
Developers zijn vaak gericht "op de vraag". Dus bij de vraag "hoe lang duurt het om dit te bouwen" vatten ze dat letterlijk op en sturen 1 uur als inschatting terug. Maar.... daarbij vergeten ze nogal wat. Want alleen even werkende code bouwen is niet voldoende.
Testproject
De klant wil dus dat klanten hun factuur in kunnen kijken. Je wilt dus valideren dat de functie die je bouwt werkt. Want het is een API-service van AFAS, dus zij kunnen de URL aanpassen. Extra headers verwachten. Andere aanpassingen doen. Dus er moet een testproject komen. Waarbij je een factuur opvraagt. Omdat het klantdata kan bevatten wil je mogelijk alleen valideren dat je een valide PDF terug krijgt. Voor het bouwen van een testproject kun je al gauw een uurtje extra inplannen. Want op een dag belt de klant: het downloaden van facturen werkt niet meer. Als er een testproject is, kun je meteen testen of het met dat scenario nog wel werkt. Werkt dat ook niet, dan weet je dat de developer ermee aan de slag mag gaan, werkt het wel, dan is in ieder geval de basiswerking nog goed.
Security
Daar gaan we. Je developer heeft de oplossing gebouwd en dan belt klant A de service-afdeling: als ze een factuur willen bekijken zien ze facturen van klant B! De service-afdeling staat bij je developer aan het bureau: wat voor k-product heb jij nu gebouwd?
Facturen bevatten vertrouwelijke informatie. Dus het kunnen aanroepen van een URL is niet voldoende. Je moet ook valideren of de persoon die ingelogd is die URL wel mag aanroepen. Mogelijk gebruik je client-side cookies om te bepalen of de persoon bij een factuur mag komen. Maar hoe goed is dat cookie beveiligd? Is de waarde een nummer van de organisatie in je database (1) en als iemand dat aanpast naar "2" , kan hij/zij dan zaken van dat bedrijf zien? Nee, natuurlijk mag dat niet! Dat moet je op een andere manier beveiligen en op een goede manier.
Of erger nog, handel je het opvragen van de factuur niet via de server af, maar wordt het opgebouwd in javascript wat in de pagina geplaatst wordt? Waardoor de persoon weet welke URL aangeroepen wordt en daar zelf wat mee kan sleutelen?
Je ziet hier dat de "simpele vraag", de klant wil vraag dat ingelogde klanten hun facturen kunnen bekijken niet een simpel antwoord oplevert. Vaak wordt niet gedacht aan het kunnen testen van functionaliteit en het "veilig houden" van data.
Doordat het "druk is met andere opdrachten". Doordat het sowieso druk is en de opdracht maar even snel doorgegeven wordt aan aan een "junior developer" of "stagiair", personen die waarschijnlijk nog geen zicht hebben op wat voor extra zaken er spelen bij zo'n ogenschijnlijk "simpele vraag". En ja, dit kan ook een "senior developer" zijn, als we het hier over een ZZP-er hebben die veel kantoorautomatisering met Excel en Acces gedaan heeft, de laatste tijd zelf plug-ins voor Wordpress maakt en trots melding maakt dat hij/zij al "20 jaar programmeerervaring heeft" en dit wel voor je kan bouwen.
Controle van je oplossing(en)
Heb je dat ook wel eens, dat je vraagt "waar ligt de kaas", het antwoord krijgt "in de koelkast!" en je tijdens het stellen van de vraag voor de koelkast staat en ja: je had er volledig overheen gekeken, die kaas ligt gewoon voor je neus!
Als je developer bent, de code bouwt om die factuur te downloaden, dan zijn er vast zaken die je mist. Want je code kan wel werken, als iemand 300 keer een URL probeert aan te roepen, 299 keer faalt, maar die laatste keer wel een factuur download, had je dat gezien? Oftewel, had je bij de 5e foutieve aanroep al gezien: dit moet een script of "bad actor" zijn die willekeurige combinaties gebruikt, die moeten we maar eens blokkeren? Vermoedelijk niet. Want hoewel het credo "security by design" is, zit dit nog niet standaard ingebakken bij alle developers. Een goede zaak dus om een externe partij eens te laten kijken of zaken goed/secure werken.
Mocht je niet weten wie je daarvoor kunt benaderen, dan adviseer ik je om eens contact op te nemen met E11even uit Heerenveen. Daar zitten mensen die weten wat ze doen. Ze blijven "bij" met de huidige security-regels.
Want bepaalde zaken die "nu" een "low"-status krijgen, kunnen volgend jaar wel een "medium" of "high' status krijgen, omdat bijvoorbeeld door AI zaken die eerst heel veel tijd namen een tijd later binnen een half uur ineens wel mogelijk zijn. En dan wordt iets wat niet heel bedreigend leek wel een aspect om rekening mee te houden.
Resumé
Als je iets moet bouwen moet je standaard denken: gaan we dit ook testbaar maken én hoe gaan we dit doen met security? Vroeger kwam je er misschien mee weg dat zaken "niet super-secure waren en gewoon werkten", maar met alle botjes en "bad actors" die op het internet actief zijn kom je daar niet meer mee weg. Dan duurt iets maar langer, dan bouwen we het maar niet als de klant het te duur vindt, maar alles is beter dan dat je iets bouwt waaraan je twijfelt of er later geen problemen of extra werk achter weg komt.