Cloudflare wijt storing aan maatregelen tegen kritieke kwetsbaarheid React

De storing bij Cloudflare vrijdag werd veroorzaakt door noodmaatregelen tegen de kritieke kwetsbaarheid in React, meldt het cloudbedrijf zelf. Door de storing functioneerde het netwerk van Cloudflare 25 minuten niet stabiel.

Volgens Cloudflare ondervond een deel van het netwerk vrijdag vanaf 9.47 uur 'aanzienlijke storingen'. Om 10.12 uur was de storing volgens het bedrijf weer verholpen. In totaal is ongeveer 28 procent van het HTTP-verkeer dat Cloudflare verwerkt getroffen. De verstoring was volgens cto Dane Knecht niet het gevolg van een cyberaanval, maar van noodmaatregelen tegen de kritieke kwetsbaarheid in React Server Components, die eerder deze week werd bekendgemaakt.

Cloudflare besloot de standaardbuffergrootte van zijn firewall voor webservers te verhogen van 128KB naar 1MB. Dit is de standaardlimiet die Next.js-applicaties toestaat. Deze maatregel werd geleidelijk doorgevoerd. Tijdens de uitrol merkte Cloudflare dat zijn interne testtool voor deze firewalls de grotere buffergrootte niet ondersteunde. Daarom besloot het team deze tool uit te schakelen.

Deze uitschakeling gebeurde via het global configuration system van Cloudflare. Dit systeem introduceert veranderingen niet geleidelijk, maar voert ze meteen wereldwijd door. Het uitschakelen van de tool veroorzaakte een bug in de code-uitvoering in de FL1-proxy van Cloudflare. Deze bug resulteerde in HTTP 500-fouten bij klanten wiens webassets door de FL1-proxy worden beheerd en de Cloudflare Managed Ruleset hebben geïmplementeerd.

De bug werd veroorzaakt door een programmeerfout in het regelsysteem van Cloudflare, specifiek hoe het systeem omgaat met de actie execute als het bedrijf een killswitch toepast. Het systeem sloeg de evaluatie van de executeactie terecht over, maar de code verwacht dat het object rule_result.execute bestaat als een dergelijke actie wordt uitgevoerd. Deze bestond echter niet, omdat de executeactie was overgeslagen. Daardoor gaf Lua een foutmelding.

"Dit is een simpele fout in de code, die jarenlang onopgemerkt was gebleven", schrijft Knecht. "Dit type codefout wordt voorkomen door talen met sterke typesystemen. In onze vervanging voor deze code in onze nieuwe FL2-proxy, geschreven in Rust, trad de fout niet op."

Het aantal succesvolle HTTP-verzoeken (Groen) en afgewezen verzoeken (rood) tijdens de storing

Reacties (58)

[Olaf van der Spek]

Cloudflare besloot de standaardbuffergrootte van zijn firewall voor webservers te verhogen van 128KB naar 1MB.

Waarom was een grotere buffer nodig?

[Kees]

De bug in React/nextjs waar ze over schrijven is er een die je kan misbruiken door in de 'POST' body van een request bepaalde parameters te zetten.

De cloudflare WAF scanned die POST-bodies op die bewuste parameters and weigert de request als hij die vind.

Maar nu zag iemand waarschijnlijk dat als hij de request maar groot genoeg maakte, die request niet gescanned werd en direct naar de server ging (die vervolgens gehacked werd).

De servers, by default, accepteren 1MB aan data, en Cloudflare scande alleen de eerste 128KB. Dat hebben ze dus geprobeert gelijk te trekken.

Het was wel deels een success. De bug kon niet meer misbruikt worden, dat de sites ook niet meer beschikbaar waren was wel een klein minpuntje.

[Stetsed]

Omdat normaal scant de WAF niet alles, want dit gebruikt te veel processing capaciteit. Hiervoor heb je dus een body limit waar in wordt gezegt dat als de body groter is dan dat dan wordt hij doorgestuurd anders niet, dit is vaak niet een probleem omdat veel kwetsbaarheden in de header zitten. Maar in deze situtatie blijkbaar niet waardoor ze hem moesten vergroten. Iets soort gelijk heb je bijna altijd ook in de WAF die je draait met traefik/nginx/enz dat je een soort gelijk limiet instelt.

[jcvw]

Dit toont maar weer eens aan dat voor grote systemen rollouts altijd gradual moeten zijn, met automatische monitoring en rollback. Rol de wijziging uit naar 0.1%, van je systemen, laat dit "inweken" en verifieer dat die nieuwe populatie blijft werken ("canarying"). Dan ga je naar 1% uiteraard weer met canarying, dan 10% en dan pas 100% van de populatie. En een rollout is niet alleen maar het uitrollen van nieuwe software, maar dus ook voor configs.

En ja, dit moet je ook doen bij dingen die "echt nu meteen" moeten, bijvoorbeeld om een outage te mitigeren. Alleen meet je dan de "inweektijd" niet in uren maar in minuten.

Zie ook https://sre.google/sre-book/reliable-product-launches/

[armageddon_2k1]

Beste stuurlui staan aan wel zoals gewoonlijk

[Webgnome]

Dat heeft er niets mee te maken in dit geval. Het is inderdaad iets dat simpelweg voorkomen had kunnen worden als er geen partijtje paniekvoetbal zou zijn gespeeld. De vragen die we moeten stellen hier zijn

• Was de React CVE daadwerkelijk een grote ramp waiting to happen?
• Is het de taak van Cloudflare om deze problemen op te lossen?
• Waarom heeft Cloudflare niet van te voren gechecked hoe het in zijn eigen pipeline zou gedragen?

Cloudflare is geen klein dienstje meer zoals ze nu al twee keer in korte tijd hebben aangetoond. Als daar iets mis gaat, gaat er in de webwereld heel veel mis. Dat mag echt wel met iets meer fale-safes en kun je niet even afdoen met 'beste stuurlui'.

Dit is een simpele fout in de code, die jarenlang onopgemerkt was gebleven", schrijft Knecht. "Dit type codefout wordt voorkomen door talen met sterke typesystemen. In onze vervanging voor deze code in onze nieuwe FL2-proxy, geschreven in Rust, trad de fout niet op.

Sorry, dit is simpelweg een kwestie van een stuk code dat niet goed gereviewd is waardoor dit probleem er in is blijven zitten. De enige reden dat je dit op had kunnen lossen met een typed / compiled taal is omdat je compiler hierover kan gaan zeuren. Echter, ook bij een niet compiled en/of typed taal zoals javascript, lua etc had je dit met de juiste tools er gewoon uit kunnen moeten kunnen vissen.

[Reactie gewijzigd door Webgnome op 6 december 2025 12:12]

[david-v]

Volgens mij heb je het artikel niet helemaal goed gelezen. Dit is een combinatie van meerdere factoren geweest, niet iets wat je simpel zou kunnen mitigeren door een goede code review te doen. Zo werkt dat niet meer bij dit soort complexe systemen.

Als dit zo simpel was dan was de meeste software vanaf dag 1 bugvrij. We weten als ontwikkelaars heel goed dat dat een utopie is bij (complexe) systemen.

[SPee]

Eens met edwinjm. Dit kan zeer zeker via reviews ontdekt worden. Je moet alleen wel goed reviewen en testen. Daar schort het dus aan. Zeker, omdat dit voor Cloudflare niet de eerste keer is. Dus daar moeten ze extra aandacht aan besteden.

Ook zelf meegemaakt. Systeem had een bug. Bleek dat recent in die code een wijziging op was geweest. Dat andere team had de code "gereviewed" en vond geen problemen. Echter, in dat stuk zat een versiecheck en controleerde ze nergens andere waardes dan de default. Waarom ze niet zelf dachten "ik voeg een check toe voor 2->3 en falende 3->2", ipv alleen 0->1 te controleren, geen idee. Maar dan was die bug snel gezien. Want 1 was de default waarde en dat versie veld werd nooit gevuld in die nieuwe code. Dus met alleen die test voor 1 kwam je niet achter die bug.

[david-v]

Je geeft zelf een voorbeeld waarbij een "review" alsnog niet hielp om een bug te vinden. Bij complexe systemen met afhankelijkheden is het zeer moeilijk om een bug te voorkomen met een review. Met (unit) testen kom je al een end, maar dit neigt meer naar integratie testen. Ook daarmee vangt je niet alles voor 100% af.

Achteraf is het heel makkelijk praten, maar om te beweren dat dit met een code review voorkomen had kunnen worden? Nee, dat gaat er bij mij niet in. Als ik het probleem uit dit artikel lees, 3 verschillende onderdelen die samen dit probleem veroorzaken. Daar kan je niet tegenop reviewen

[supersnathan94]

Achteraf is het heel makkelijk praten, maar om te beweren dat dit met een code review voorkomen had kunnen worden? Nee, dat gaat er bij mij niet in.

Eens hoor.


Ik heb ook met een codereview mij wel eens afgevraagd, "hee volgens mij is dat nog niet volledig geschikt voor prod" (config wijziging), maar doordat ik niet helemaal in de materie zat er vooral niet al te gronig naar gekeken (men zal wel beter weten dan ik),

Bleek dat ik toch gelijk had en er daardoor wel mensen een behoorlijke tijd buiten in de kou stonden te wachten.

een code review had dit af kunnen vangen, maar moet je wel diep genoeg in de materie zitten. Je wil dit dan ook vooral op tests kunnen doen. Dus behavior driven en dan daarna ook nog verificatie in prod of het werkt.

[SPee]

Je geeft zelf een voorbeeld waarbij een "review" alsnog niet hielp om een bug te vinden.

Dat ligt eraan hoe streng men ernaar kijkt. In dit geval enkel "ziet het er goed uit? compiled het?" en verder niet. Als je dat doet, dan doe je geen echte review en had je net zo goed de tijd kunnen besparen.

Bij een systeem met 24/7 grootverbruik, dan zou je wel een review verwachten die een stapje verder gaat. In de luchtvaart, ruimtevaart en gezondheidszorg zijn de eisen een flink stuk hoger voordat je zelf maar een kleine aanpassing mag maken. Als je *iets* beter naar de wijziging had gekeken of naar welke testen er (niet) waren, dan kon die fout er eerder uitgehaald worden. Dit is geen hobbyproject.

[david-v]

Je legt duidelijk het probleem neer bij de mens, de reviewer. Ik hoef je niet te vertellen dat iedereen anders is en anders naar een PR kijkt. Achteraf is het zo simpel om maar te focussen op één deel van het geheel, de PR. Daarmee ga je niet voorkomen dat het nog een keer gebeurd. Je moet alle delen meenemen om risicos nog verder te verkleinen (100% voorkomen is onmogelijk).

Ik heb daarom veel moeite met het stellen dat een goeie PR dit probleem, die ontstaan is door een combinatie van factoren van verschillende deelsystemen, had kunnen voorkomen.

[Ozzy]

Precies, en daarom hoor je in de luchtvaart ook nooit over problemen met de software. Of, hey wacht eens even: nieuws: Duizenden Airbus A320-vliegtuigen mogen niet vliegen tot software geüpdatet is

Maar goed, in de zorg gaat het wel altijd goed: nieuws: Amerikaanse FDA waarschuwt voor kwetsbaarheden in pacemakers

Het is gewoon een illusie dat je bugs voorkomt, je controles en tests 100% dekkend zijn, je uitrollen gegarandeerd foutloos zijn.

Het is minstens zo belangrijk dat je dat accepteert en dat je er rekening mee houdt dat het fout gaat.

[edwinjm]

Een goede code review had dit wel degelijk ondervangen. Als de executie conditioneel is, dan moet het uitlezen van het executieresultaat ook conditioneel zijn.

Als code zo complex is geworden dat het onbegrijpelijk wordt, dan moet de code geherstructureerd worden.

Complexe systemen zijn geen excuus om bugs te accepteren of code reviews slecht te doen.

[jcvw]

Code review is belangrijk, maar niet genoeg. Unit testing is niet genoeg. Testen in productie via gradual rollouts (0.1, 1, 10, 100 procent) is in grote systemen essentieel.

[familyman]

In dit geval lijkt me echter dat het probleem zo groot is, dat veel code nodig is.

In allerlei kleinere componenten refactoren zou zo maar het zaadje kunnen leggen van veel grotere storingen.

[Bedge85]

Het probleem wat er speelt is Hindsight bias. In dit geval, achteraf lijkt de storing eenvoudig te voorkomen had kunnen worden terwijl dat in werkelijkheid (waarschijnlijk) niet het geval is.

Een goede root cause analysis is natuurlijk wel relevant, daar kun je van leren. Maar elke storing voorkomen lukt niet. Vergeet ook niet dat er vermoedelijk honderden storingen voorkomen worden door goed lopende processen, en enkel wanneer het fout gaat is dit zichtbaar.

Dit betekent niet dat er niet naar verantwoordelijkheid gekeken moet worden bij een storing. Bijvoorbeeld bij de CrowdStrike storing in 2024 was het snel duidelijk dat CrowdStrike enorme steken had laten vallen en de storing in alle redelijkheid voorkomen had kunnen worden. Bij Cloudflare heb ik dat idee tot nu toe nog nooit gehad op het gebied van engineering, en ook in dit geval heb ik dat niet.

[Reactie gewijzigd door Bedge85 op 6 december 2025 13:06]

[Webgnome]

Mee eens. Het mooi van Cloudflare is dat ze open zijn, zover ik kan zien, in wat er gebeurd is, hoe ze het hebben ontdekt en opgelost.

[FredFlitsPaal]

Eens. Goede comment. Als ik dit artikel zo lees dan is het echt niet zomaar een bug. Als ik kijken naar mijn eigen software team en we hebben de boel echt wel goed op orde, dan had de outage veel langer geweest. 25 minuten voor zo'n complex issue is echt niet veel. Daar heb je heel veel hele begaafde engineers en hele goede processen voor nodig.

[familyman]

En telemetrie, die lijkt me ook gaaf voor deze hut.

[kodak]

Het is inderdaad iets dat simpelweg voorkomen had kunnen worden als er geen partijtje paniekvoetbal zou zijn gespeeld.

Je trekt een conclusies zonder je eigen vragen beantwoord te hebben. Waarop baseer je nu dat het paniekvoetbal zou zijn?

We lezen niet wat hun motivaties waren. Wel geven ze aan hun eigen software niet duidelijk te kunnen vertrouwen. En met een publiek uit te voeren remote code execution dat mogelijk in hun eigen systemen bestaat is het dus te verwachten dat ze snel andere maatregelen proberen.

[SPee]

Waarom kan een klant niet zelf kiezen welke filters hij wil instellen? Als je geen react gebruikt, heb je die filter niet nodig. En dan gebruik je die filter niet en zit je ook niet bij de groep klanten met problemen.

[jcvw]

@armageddon_2k1

Sorry, been there, done that. Ik ben al 15 jaar Site Reliability Engineer bij Google. Zie https://sre.google/sre-book/production-environment/

[Reactie gewijzigd door jcvw op 6 december 2025 20:33]

[erikieperikie]

Ik doe bij geleidelijke uitrol niet x10, maar ongeveer x3. Bijvoorbeeld ((0,1%,) 0,3%,) 1%, 3%, 10%, 33%, 100%. Dat gaat iets minder snel, maar nog steeds rap aan het einde, voor wat een wat meer defensieve uitrol. Programmatisch uitrollen kan ook op basis van bepaalde parameters, maar ik zit liever aan de knoppen tijdens het monitoren.

[Frenziefrenz]

Het is misschien leuk om op te merken dat exact dit gedrag recent werd aangeklaagd in „Cloudflare considered harmful”.

Being a comment spam filtering service isn't the only thing Cloudflare is trying to do besides being a CDN. They also claim to use their CAPTCHAs to mitigate other “abusive” traffic, like “harvesting e. mail addresses”.
[...]
This is a fundamentally broken practice. Attempting to filter for SQL injection at the CDN level is an excercise in futility and security theatre. This is the “Web Application Firewall” idea, the absurd idea that grepping requests/responses for known-to-be-naughty patterns is an adequate cure for vulnerable web applications. In reality it isn't trustworthy or accurate because it can't be.

If I try to login on a website with the username ' OR 0=0 --, Cloudflare has no way of knowing whether this is a SQL injection attack or just a peculiar username which the website has decided to legitimately issue. Cloudflare has no way of knowing if the website even uses SQL for data storage.

If I post ' OR 0=0 -- in a comment, Cloudflare has no way of knowing whether this is an SQL injection attack, or whether it will actually work, or whether I'm actually posting a comment discussing SQL injection and including examples (at which point this actually becomes a form of censorship).

What using Cloudflare does mean is that Cloudflare will randomly cause DoS to users if it thinks they're trying to use a pattern of text to which Cloudflare is by design allergic. The circumstances in which these denials of service occur are, of course, ill defined and in no way exhaustively enumerated, so using Cloudflare presents an intense and unaccounted liability in terms of availability and content neutrality for any website. It is essentially a way to make your website unreliable and fail randomly.

The “web application firewall” concept is fundamentally flawed in all instances, because it falsely presupposes that a blind intermediate proxy can reliably assess the semantic meaning of data transmitted, which is in actual fact impossible. Since this kind of “service” is part of the Cloudflare value proposition and an attempt to add a profit-making value-add, Cloudflare has essentially built their entire business on doing something which is a bad idea and which cannot be reliably implemented.

[Reactie gewijzigd door Frenziefrenz op 6 december 2025 11:40]

[eborn]

Leuk verhaal, maar net als met zoveel dingen geldt: elk klein beetje helpt. Het hoeft niet perfect te zijn, maar helemaal als je te maken hebt met software waar je niet alle ins-en-outs van kent, dan is het prettig om op een hoger niveau iets van filtering te hebben. Zodat de meest obvious fouten in ieder geval niet je hele applicatie open leggen.

En als je inderdaad besluit om zo'n gekke gebruikersnaam te gebruiken, dan krijg je keurig een foutmelding.

[YoMarK]

Zo kan je het zien, maar er heerst in bepaalde takken van IT het idee dat een WAP 'alleen' kan zorgen voor goede beveiliging. Dit is omdat met fundamenteel niet snapt wat een WAP doet, en vooral wat het niet doet.
Heel kort door de bocht, men denkt dat met het 'aanschaffen' van een WAP, het daarna OK is om een brakke applicatie aan het internet te knopen.
In de praktijk fietsen 9/10 exploits er gewoon doorheen.

[bzzzt]

Wat mij het meest stoort is dat heel veel van die WAP toestand botweg overbodig is. Leuk dat je antieke Apache HTTPD bugs of PHP vulnerabilities afvangt. Kan je mooi een dashboardje maken hoeveel 'aanvallen' je tool afslaat, maar die exploits zijn voor een enigszins moderne webservice stack in de praktijk geen enkel risico.

[Stukfruit]

Eigenlijk ook wel weer mooi om te zien dat zelfs Cloudflare zelf over hun eigen limieten valt.

* Stukfruit is er al vaker dan één keer over gevallen en kon daarom een kleine grinnik niet onderdrukken

[latka]

Dus een probleem door weak typing in lua om een probleem in een weakly typed ecosysteem van react/javascript te beperken. Ik zie een patroon.

[armageddon_2k1]

Weak typing had niks te maken met de CVE van React

[Immutable]

En vaak dat men niet alle fout scenarios afhandelt. Ik zie vaak genoeg code waarbij... Oh X faalt? Gewoon programma laten stoppen met error. Dat is lui gedrag. Waarom niet zo programmeren zodat je alle shit correct afhandelt zodat er een volledige recovery is en het programma door kan gaan.

[Reactie gewijzigd door Immutable op 7 december 2025 08:42]

[thePiett]

Ik denk dat de gemiddelde ontwikkelaar alles graag correct afhandeld. Echter Manager X hangt in je nek dat alles gisteren al klaar had moeten zijn. Je weet hoe het gaat

[Zenomyscus]

Tijdens de uitrol merkte Cloudflare dat zijn interne testtool voor deze firewalls de grotere buffergrootte niet ondersteunde. Daarom besloot het team deze tool uit te schakelen.

Tja. Meer dan 'tja' kan ik er eigenlijk niet over zeggen. Dit behoeft verder geen uitleg, want iedere serieuze ontwikkelaar weet dat dit vragen om problemen is en nogal dom is. Zorg dat al je tooling werkt voordat je een uitrol doet en wijk niet af van het protocol. Dat is er niet voor niets.

[Bedge85]

De aanpassing moest onder tijdsdruk worden doorgevoerd in verband met een kritieke kwetsbaarheid React. Het systeem van ClouFlare is zo groot en complex dat niet alle risico's afgedekt kunnen worden voor het uitrollen van een aanpassing.

[Reactie gewijzigd door Bedge85 op 6 december 2025 09:57]

[--MeAngry--]

Dit, een kritieke kwetsbaarheid brengt nog veel grotere risico’s met zich mee dan 25 minuten downtime. Dat maakt het niet minder vervelend, maar wel dat de prioriteiten goed op orde zijn.

[dasiro]

er was geen 25 minuten downtime, er kwamen 25 minuten lang in 28% van de requests error 500 antwoorden, de overige 72% kreeg het normale antwoord (wat ook nog steeds een error kan zijn).

[Sandor_Clegane]

Dit maakt het niet beter. Waarom zijn ze zo belangrijk voor het internet als ze het zelf niet snappen?

[Firestorm666]

Het gaat niet over het niet-snappen. Er was een bug in die jarenlang onopgemerkt is geweest. Hoe groter & complexer je omgeving is, hoe groter die kans is.

Eigenlijk is de tl;dr: shit happens, zeker als er een noodsituatie zich voordoet. Een kritiek beveiligingslek is een noodsituatie.

[Blokker_1999]

Je moet hier een keuze maken. Je bent vatbaar voor een RCE welke mogelijks heel je infra en heel je bedrijf in gevaar brengt. Dan is het niet zo eenvoudig als zeggen dat je er maar even enkele weken development werk tegenaan gaat gooien om het op te lossen en dat je ondertussen gewoon kwetsbaar gaat blijven.

En dat de testtool er niet mee overweg kan lijkt me nog niet eens de root cause te zijn dat je een resultaat verwacht dat niet altijd bestaat ergens anders in de lijn. Dat dat nooit is opgemerkt kan gebeuren, maar dan moet je QA team misschien ook eens nakijken welke test cases zij mogelijks nog over het hoofd zien. Een belangrijke optie in je software stack hebben, maar die nooit uittesten lijkt hier een belangrijke fout te zijn geweest, en in geval van nood moet je dus on-the-fly schakelen.

[Arrigi]

Goeie. Hoe kán het dat de bug in React door alle testing is geraakt? Zorg eerst voor correcte testing voor je mogelijk dergelijk kwetsbare code publiceert.

Toch?

[bwerg]

Omdat testen per definitie onvolledig is? Dat maakt tests niet "incorrect".

[Immutable]

Nee hoor. Software bestaat die wiskundig 100% correct moet zijn. Waarbij de testen dus 100% volledig zijn. Denk aan Spark ADA of oCaml.

Enige punt is. Is jou logica dat je ontworpen hebt wel correct? Maar dat is een design fout. Niet echt een bug.

[bwerg]

Dan heb je het niet over testen maar over een correctheidsbewijs. Testen is het uitvoeren van code om te zien of er het juiste antwoord uit komt, dat kan alleen volledig zijn als de mogelijke invoer en de toestandsruimte eindig is, en klein genoeg om alle mogelijke invoer en toestanden te "brute-forcen". Zodra je trucjes gaat uitvoeren om niet de volledige ruimte van invoer en toestanden af te gaan heb je het over een andere verificatietechniek dan testen.

[elmuerte]

Om Edsger Dijkstra te quoten: Program testing can be used to show the presence of bugs, but never to show their absence!

[david-v]

Je kan niet alles 100% dekken met testen. Een kleine functie of applicatie zou misschien nog wel kunnen als je er veel tijd in steekt, maar het loont simpelweg niet, al helemaal niet voor grote codebases en complexe systemen.

[Immutable]

Je stelling klopt niet. 100% dekking is wel degelijk haalbaar én loont juist bij complexe systemen.

Formele verificatie bestaat. Talen als Coq, Agda, Lean en Idris maken wiskundig bewijs van correctheid mogelijk. Niet "testen", maar bewijzen dat je code correct is voor alle mogelijke inputs.

Risico schaalt mee. Hoe complexer het systeem, hoe hoger de faalkosten. Denk aan luchtvaart (DO-178C) of medische software. Daar is 100% dekking geen luxe maar eis.

[david-v]

Je stelling klopt niet. 100% dekking is wel degelijk haalbaar én loont juist bij complexe systemen.

Ook met 100% coverage kan je nog steeds bugs hebben, het is geen garantie. Ik heb bij een event van sonar(qube) precies deze vraag gesteld. Moest je nou wel of niet 100% streven. Het antwoord was simpel, nee. De eigen code van sonarqube haalt dat niet en blijft ergens in de 85% hangen.

De meeste bugs die wij moeten oplossen zijn functionele bugs of zijn technisch van aard (memory leak of extreem CPU verbruik). Het is de combinatie van alles, code review, unittest. Integratietest, ketentest, sast, dast, visuale en handmatige tests enz die ervoor moeten zorgen dat je zo min mogelijk bugs hebt.

Bugvrij bestaat niet en gaat je ook nog lukken, al helemaal niet met zeer complexe systemen.

Formele verificatie bestaat. Talen als Coq, Agda, Lean en Idris maken wiskundig bewijs van correctheid mogelijk. Niet "testen", maar bewijzen dat je code correct is voor alle mogelijke inputs.

Ik weet dat dat bestaat, heb het vaak genoeg moeten doen tijdens mijn studie. Dat is nog wel te doen voor een functie, maar als je dit gaat doen voor een codebase van een miljoen regels code gaat dat niet lukken. Laat staan als je allerlei koppelvlakken hebt.

Risico schaalt mee. Hoe complexer het systeem, hoe hoger de faalkosten. Denk aan luchtvaart (DO-178C) of medische software. Daar is 100% dekking geen luxe maar eis.

Je beschrijft nu maar een klein deel van het geheel, unittesten van software, daarmee voorkom je niet alle bugs. Juist door de combinatie van meerdere delen wat ik hier boven noem heb je meer kans van slagen. Daarom heb ik moeite met de stelling "dit had je ontdekt met een code review" of "met 100% coverage had je dit wel ontdekt". Zo werkt het simpelweg niet bij complexe systemen

[Immutable]

Ik vind een design fout, geen bug.

[bwerg]

Je spreekt je zelf tegen. De stelling van @david-v is dat je met testen geen 100% dekking hebt, en zoals je zelf al zegt: een correctheidsbewijs is geen testen.

Doorgaans is formele verificatie ook alleen haalbaar in software waarin de gehele stack niet te veel interactie en abstracties heeft. Bij embedded systemen is dat bij uitstek het geval. Relatief weinig interactie met de buitenwereld, vaak ook geen abstracties nodig om het op verschillende omgevingen te draaien (OS/hardware/virtualisatie), het wordt voor een specifieke hardwareomgeving gemaakt. Kijk je in een typische web-omgeving, dan heb je een hele zwik cloud-componenten en duizend externe libraries. Tja, succes met een correctheidsbewijs daarvan.

[Reactie gewijzigd door bwerg op 7 december 2025 20:54]

[syl765]

Testen zijn leuk. Maar testen zijn geschreven op de zaken die je weet.

Als er een bug in de code zit die zich alleen openbaart als x en y de waarde a of b hebben dan kom je daar pas achter als het zich voordoet. Dan kun je daar weer een test op maken. Voor die tijd ben je zogezegd blind.

[Immutable]

Niet helemaal waar. Property-based testing (zoals Hypothesis of QuickCheck) genereert automatisch duizenden willekeurige inputcombinaties om precies dit soort edge cases te vinden. Je test dan niet "x=5 geeft y=10", maar "voor alle x en y geldt eigenschap Z". Fuzzing doet iets vergelijkbaars. Je bent dus niet per se blind.

[Barsonax]

He het was dus niet dns?

[Technoid]

Jawel, juist wel.

Als je die had geconfigureerd naar je webserver rechtstreeks ipv naar cloudflare had je nergens last van

[naaitsab]

Van achter de PC altijd makkelijk praten maar is dit niet erg knullig uitgevoerd? Lijkt me dat je na een test een gefaseerde 'rolling update' doorvoert en niet de helft van je dienstverlening op zwart gooit. Waarbij de communicatie ook nog eens belabberd was. En ja dit is nog altijd beter dan niks doen, dat moge duidelijk zijn, dit lek is niet zo maar een bugje.

Geeft maar weer eens aan hoe kwetsbaar het internet anno 2025 eigenlijk is. Bedrijven als Cloudflare hebben veel te veel marktaandeel wat het voor de alternatieven lastig maakt. Wat de stabiliteit niet ten goede komt.

[kuurtjes]

Ze willen natuurlijk dat hun WAF tegen mogelijke aanvallen kan beschermen. Waarschijnlijk vonden ze de veiligheid belangrijk genoeg om de update te forceren in plaats van rustig uit te rollen. Als je je klanten wilt beschermen is het waarschijnlijk zelfs minder erg om downtime te hebben dan dat er iemand gehackt wordt.

[GertMenkel]

Het duurde wel een paar minuten tot de storing op de website stond, maar zo erg vond ik het ook weer niet verlopen. Al met al een half uurtje problemen vind ik zo erg nog niet, dat kan je ala gebruiker ook overkomen als iemand in je netwerk ene scraper draait en je IP tijdelijk op de gevaarlijst wordt gezet.

Dit is niets vergeleken met de vorige storing die lang duurde en maar weinig duidelijkheid bood. Ik geloof niet dat ze met deze storing enige SLA's hebben doorbroken.

[Reactie gewijzigd door GertMenkel op 6 december 2025 11:08]

[Xerxes249]

Ik vind zulke artikelen wel moeilijk lezen zeg tjonge.