Verouderde API-versies blijven bereikbaar

Wanneer een team een nieuwe versie van zijn API uitbrengt, gaat de aandacht naar wat er nieuw is. De oude versie blijft draaien omdat er nog clients op zitten, en verdwijnt daarmee uit beeld, niet uit de infrastructuur. Hieronder leest u waarom die achtergelaten versie precies de controles mist die u sindsdien hebt toegevoegd.

Waarom blijft een oude API-versie bestaan?

Van verouderde API-versies die bereikbaar blijven spreken we wanneer een oudere generatie endpoints naast de actuele blijft draaien zonder hetzelfde onderhoud te krijgen. Het is geen ontwerpfout maar een gevolg van hoe API’s in de praktijk evolueren: u kunt bestaande clients niet van de ene dag op de andere afsluiten, dus draait de oude versie er even naast. Die “even” wordt jaren.

Wat er intussen gebeurt, is het eigenlijke probleem. Elke verbetering aan de nieuwe versie: een strengere autorisatiecontrole, een schema voor invoervalidatie, een snelheidsbeperking, minder velden in het antwoord, wordt daar doorgevoerd en niet in de oude. Het verschil groeit stilzwijgend, en de oude versie wordt daarmee een omweg om al die verbeteringen heen.

Vergelijk het met een gebouw waar een nieuwe entree met toegangscontrole is gebouwd, terwijl de oude ingang aan de achterkant open blijft omdat een paar mensen nog een oude sleutel hebben. Alle aandacht en alle maatregelen zitten bij de nieuwe deur. De inbreker gaat naar de oude.

Hoe vindt een aanvaller oude API-versies?

Kwetsbaar:

// De actuele versie, met alle controles
app.get('/api/v3/klanten/:id',
  vereistLogin,
  vereistRol('accountmanager'),
  snelheidsbeperking,
  async (req, res) => {
    const klant = await klanten.zoekVoorBeheerder(req.params.id, req.gebruiker.id);
    res.json(klantSamenvatting(klant));            // beperkte velden
  },
);

// De oude versie, nooit meer aangeraakt
app.get('/api/v1/klanten/:id', vereistLogin, async (req, res) => {
  const klant = await klanten.zoek(req.params.id);
  res.json(klant);                                  // het volledige record
});

Beide routes bestaan, allebei op dezelfde server. De actuele controleert de rol, beperkt het tempo, kijkt of de klant bij deze accountmanager hoort en geeft alleen de bedoelde velden terug. De oude vraagt om een geldige sessie en doet verder niets. Een aanvaller met een gewoon account hoeft alleen het versienummer te wijzigen:

GET /api/v3/klanten/8891 HTTP/1.1     → 403 Geen toegang
GET /api/v1/klanten/8891 HTTP/1.1     → 200 OK, volledig record

Het vinden ervan kost weinig moeite. Versienummers zijn voorspelbaar, oude paden staan vaak nog in gearchiveerde documentatie, en een verouderde mobiele applicatie die nog in omloop is, verraadt precies welke endpoints er ooit waren.

Veilig:

// Elke versie loopt door dezelfde autorisatie- en validatielaag
const basis = [vereistLogin, snelheidsbeperking, controleerToegang];

app.get('/api/v3/klanten/:id', ...basis, v3.toonKlant);
app.get('/api/v2/klanten/:id', ...basis, v2.toonKlant);

// En wat niet meer ondersteund wordt, is écht dicht
app.use('/api/v1', (req, res) => {
  res.status(410).json({
    fout: 'Deze API-versie wordt niet meer ondersteund',
    documentatie: 'https://portaal.example/api/migratie',
  });
});

De gedeelde laag zorgt dat een verbetering aan de autorisatie meteen voor elke ondersteunde versie geldt. Daarnaast een versie die u uitfaseert, geeft een 410 terug in plaats van stilzwijgend te blijven werken, dat is duidelijk voor de clients die er nog op zitten en sluit de omweg af.

Wat is de impact van verouderde API-versies?

De ernst loopt van middelzwaar tot hoog en wordt bepaald door hoe groot het gat tussen de versies is geworden. Bij een verschil van enkele maanden valt het mee; bij een oude versie die jaren geleden is bevroren, kunnen alle inmiddels toegevoegde controles ontbreken.

Deze bevinding doet vooral de waarde van uw eigen verbeteringen teniet. Een team dat de autorisatie op objectniveau netjes heeft ingericht, de invoervalidatie heeft aangescherpt en het aantal teruggegeven velden heeft beperkt, heeft dat allemaal in de nieuwe versie gedaan. Zolang de oude bereikbaar is, is de effectieve beveiliging die van de zwakste versie.

Oude versies zijn bovendien zelden in beeld zijn bij monitoring. Er wordt gealarmeerd op afwijkend gebruik van de actuele endpoints; de oude staan vaak niet eens in het overzicht. Een aanvaller die daar systematisch gegevens ophaalt, valt daardoor minder snel op.

Hoe spoor je verouderde API-versies op?

Een tester probeert voor elk gevonden endpoint of er andere versies bestaan: het versienummer verlagen, andere schrijfwijzen proberen, en zoeken naar paden als /api/oud, /api/beta of /api/intern. Voor elk gevonden endpoint wordt vervolgens vergeleken welke controles er wél en niet zijn.

Daarnaast worden bronnen buiten de applicatie gebruikt. Gearchiveerde documentatie, oude versies van de mobiele applicatie, JavaScript-bundels van eerdere releases en zoekmachineresultaten leveren regelmatig endpoints op die nergens meer worden genoemd maar nog gewoon antwoorden. Ook wordt gekeken naar acceptatie- en testomgevingen die vanaf internet bereikbaar zijn, omdat die vaak op een oudere versie draaien met vergelijkbare gegevens. AssistSec stemt die inventarisatie af met uw eigen overzicht, omdat het verschil tussen wat er volgens de documentatie draait en wat er werkelijk antwoordt, meestal de kern van de bevinding is.

Hoe voorkom je verouderde API-versies?

• Houd een actueel overzicht bij van alle API-versies en endpoints die daadwerkelijk bereikbaar zijn.
• Laat elke ondersteunde versie door dezelfde autorisatie-, validatie- en snelheidslaag lopen.
• Kondig het uitfaseren van een versie aan met een einddatum en handhaaf die.
• Antwoord op afgesloten versies met een duidelijke 410, in plaats van ze stilzwijgend te laten draaien.
• Gebruik uw logbestanden om te zien wie een oude versie nog gebruikt, en benader die gebruikers gericht.
• Verwijder testroutes, tijdelijke koppelingen en vervangen endpoints zodra ze niet meer nodig zijn.
• Scherm acceptatie- en testomgevingen af met netwerkbeperkingen of authenticatie.
• Neem alle versies mee in monitoring en alarmering, niet alleen de actuele.
• Controleer bij een beveiligingsverbetering of die ook geldt voor de oudere versies die nog draaien.