API drošība nav funkcija, ko pieskrūvē pēc palaišanas. Tas ir pamata arhitektūras lēmums, kas nosaka, kā visa sistēma apietas ar uzticēšanos, datu plūsmu un kļūmju scenārijiem. Šajā ceļvedī apkopoti modeļi, kas palīdz novērst datu noplūdes, neradot lieku berzi.
Ceļvedis aptver četrus pīlārus, ko piemērojam katrā uzņēmuma API projektā: autentifikācijas arhitektūru, pieprasījumu ierobežošanu, ievades validāciju un audita žurnālus.
Autentifikācijas arhitektūra: vairāk nekā vienkārši marķieri
Visbiežākā kļūda, ko redzam uzņēmumu API, ir autentifikācijas uztveršana kā viena slāņa. Produkcijas API, kas apkalpo vairākus klientus, iekšējos servisus un trešo pušu integrācijas, vajag slāņotu autentifikācijas stratēģiju.
Lietojiet īslaicīgus JWT ar atjaunošanas marķieru rotāciju
Piekļuves marķieriem jābeidzas 15 minūšu laikā. Atjaunošanas marķieri jārotē katrā lietošanas reizē, iepriekšējo marķieri uzreiz anulējot. Tas ierobežo kompromitēta marķiera postījumu rādiusu un padara nozagtus akreditācijas datus nederīgus jau pēc neilga laika.
// Token configuration - keep access tokens short-lived
const tokenConfig = {
accessToken: {
expiresIn: '15m',
algorithm: 'RS256' // Asymmetric - verify without the signing key
},
refreshToken: {
expiresIn: '7d',
rotateOnUse: true, // Issue new refresh token on each use
reuseDetection: true // Flag if old refresh token is reused
}
};Karogs reuseDetection ir kritiski svarīgs. Ja jau rotēts atjaunošanas marķieris tiek izmantots vēlreiz, tas norāda uz marķiera zādzību. Tādā brīdī anulējiet visu marķieru saimi un pieprasiet atkārtotu autentifikāciju.
Ieviesiet API atslēgu tvērumus servisu savstarpējiem izsaukumiem
Ne katrs API lietotājs ir cilvēks. Iekšējiem mikroservisiem un trešo pušu integrācijām bieži vajag mašīnu savstarpēju autentifikāciju. Lietojiet API atslēgas ar tvērumiem un skaidri piešķirtām atļaujām, nevis koplietojiet servisa kontu akreditācijas datus.
// Scope-based API key validation middleware
function validateApiKey(requiredScopes) {
return async (req, res, next) => {
const key = req.headers['x-api-key'];
const client = await keyStore.lookup(key);
if (!client || client.revoked) {
return res.status(401).json({ error: 'Invalid API key' });
}
const hasScopes = requiredScopes.every(
scope => client.scopes.includes(scope)
);
if (!hasScopes) {
auditLog.warn('scope_violation', { client: client.id, requiredScopes });
return res.status(403).json({ error: 'Insufficient permissions' });
}
req.client = client;
next();
};
}Katrai API atslēgai jābūt piesaistītai konkrētai klienta identitātei, ar noteiktu tvērumu kopu un iespēju to atsaukt neatkarīgi no citām. Glabājiet atslēgas jauktā (hash) veidā, nekad atklātā tekstā.
Pieprasījumu ierobežošana: pieejamības aizsardzība, netraucējot likumīgos lietotājus
Pieprasījumu ierobežošana nav tikai ļaunprātīgas izmantošanas novēršana. Tā nodrošina taisnīgu resursu sadali starp visiem API lietotājiem un pasargā lejupējos servisus no kaskādes kļūmēm.
Ieviesiet pakāpeniskus ierobežojumus
Dažādiem galapunktiem ir atšķirīgas izmaksas. Vienkārša datu uzmeklēšana ir lēta; pārskata ģenerēšanas galapunkts, kas izsauc datubāzes agregācijas, ir dārgs. Ierobežojumiem jāatspoguļo šī realitāte.
// Tiered rate limit configuration
const rateLimits = {
standard: {
windowMs: 60 * 1000, // 1 minute window
max: 100, // 100 requests per minute
keyGenerator: (req) => req.client?.id || req.ip
},
expensive: {
windowMs: 60 * 1000,
max: 10, // 10 requests per minute for heavy endpoints
keyGenerator: (req) => req.client?.id || req.ip
},
authentication: {
windowMs: 15 * 60 * 1000, // 15 minute window
max: 5, // 5 attempts per 15 minutes
keyGenerator: (req) => req.ip // Always by IP, not by account
}
};Autentifikācijas galapunktiem pienākas īpaša uzmanība. Ierobežojiet tos pēc IP adreses, nevis pēc konta identifikatora, lai novērstu akreditācijas datu pildīšanas (credential stuffing) uzbrukumus, kas rotē dažādus lietotājvārdus.
Atgrieziet ierobežojumu galvenes
Vienmēr paziņojiet klientiem ierobežojuma stāvokli ar standarta galvenēm: X-RateLimit-Limit, X-RateLimit-Remaining un X-RateLimit-Reset. Korekti klienti tās izmantos, lai paši samazinātu tempu, pirms sasniedz robežu, tā mazinot kopējo slodzi uz ierobežošanas infrastruktūru.
Ievades validācija: neuzticieties nekam, kas nāk no tīkla
Katrs baits, kas nonāk Jūsu API, ir potenciāli naidīgs. Ievades validācija ir pirmā aizsardzības līnija, un tai jābūt gan stingrai, gan vienādai visos galapunktos.
Validējiet shēmas līmenī, nevis biznesa loģikā
Lietojiet shēmu validācijas bibliotēkas, lai definētu pieļaujamās ievades formu, pirms tā sasniedz biznesa loģiku. Tas skaidri nodala jautājumus "vai tas ir strukturāli derīgs?" un "vai tam ir biznesa jēga?".
// Schema-first validation with explicit constraints
const createOrderSchema = {
type: 'object',
required: ['items', 'shippingAddress'],
additionalProperties: false, // Reject unexpected fields
properties: {
items: {
type: 'array',
minItems: 1,
maxItems: 100, // Prevent payload bombs
items: {
type: 'object',
required: ['productId', 'quantity'],
properties: {
productId: { type: 'string', pattern: '^[a-zA-Z0-9-]{1,64}$' },
quantity: { type: 'integer', minimum: 1, maximum: 9999 }
}
}
},
shippingAddress: { $ref: '#/definitions/address' },
notes: { type: 'string', maxLength: 500 }
}
};Direktīva additionalProperties: false bieži tiek aizmirsta, taču tā ir kritiski svarīga. Tā neļauj uzbrucējiem iesūtīt negaidītus laukus, kurus varētu apstrādāt lejupējās sistēmas ar citiem validācijas noteikumiem.
Attīriet ne tikai ievadi, bet arī izvadi
Ievades validācija aptur ļaunprātīgu datu nokļūšanu sistēmā. Izvades kodēšana neļauj tiem nodarīt kaitējumu, kad tie sistēmu atstāj. Vienmēr kodējiet datus atbilstoši izvades kontekstam - HTML, JSON, SQL vai čaulas komandām. Nekad nepieņemiet, ka saglabātie dati ir droši tikai tāpēc, ka tie tika validēti ienākot. Validācijas noteikumi mainās, kļūdas gadās, un no mantotām sistēmām migrēti dati var neatbilst pašreizējiem standartiem.
Audita žurnāli: kriminālistikas pēdas veidošana
Kad notiek drošības incidents, audita žurnālu kvalitāte nosaka, vai spējat saprast notikušo un ierobežot kaitējumu. Uztveriet audita žurnālus kā pilnvērtīgu funkciju, nevis kā pēcdomu.
Reģistrējiet autentifikācijas notikumus pilnībā
Katram autentifikācijas notikumam - veiksmīgam vai neveiksmīgam - jārada audita ieraksts. Iekļaujiet klienta identitāti, IP adresi, lietotāja aģentu, laika zīmogu un iznākumu. Neveiksmīgiem mēģinājumiem reģistrējiet neveiksmes iemeslu, neatklājot informāciju, kas varētu palīdzēt uzbrucējam.
// Structured audit log entry
function logAuthEvent(event) {
const entry = {
timestamp: new Date().toISOString(),
eventType: event.type, // 'login_success', 'login_failure', 'token_refresh'
clientId: event.clientId,
ip: event.ip,
userAgent: event.userAgent,
outcome: event.outcome,
metadata: {
method: event.method, // 'password', 'api_key', 'oauth'
failureReason: event.outcome === 'failure' ? event.reason : undefined,
tokenFamily: event.tokenFamily
}
};
// Write to append-only audit store - separate from application logs
auditStore.append(entry);
}Nodaliet audita žurnālus no lietotnes žurnāliem
Audita žurnāliem jānonāk atsevišķā, tikai papildināmā krātuvē ar savām piekļuves kontrolēm un glabāšanas politiku. Lietotnes izstrādātājiem nedrīkst būt rakstīšanas piekļuves audita pēdām. Šī nodalīšana nodrošina, ka kompromitēta lietotne nevar noslēpt savas pēdas, mainot audita ierakstus.
Labākās audita žurnālu sistēmas ir tās, kuras nekad nav jālasa - bet, kad tās vajag, tajās ir viss, lai atjaunotu, kas notika, kurš to izdarīja un kad.
Nosakiet glabāšanas politiku laikus
Nosakiet, cik ilgi glabāsiet audita datus, pirms sākat tos veidot. Normatīvās prasības atšķiras, taču lielākajā daļā uzņēmumu vidēm vajag vismaz 12 mēnešus detalizētu žurnālu un 7 gadus apkopotu ierakstu. Iestrādājiet arhivēšanu un rotāciju žurnālu plūsmā jau no pirmās dienas, nevis pielāgojiet to vēlāk, kad krātuves rēķins kļuvis par problēmu.
Viss kopā
API drošība nav kādas vienas metodes nevainojama ieviešana. Tā ir vairāku aizsardzības slāņu kārtošana tā, lai kļūme vienā jomā neapdraudētu visu sistēmu. Autentifikācija novērš nesankcionētu piekļuvi. Pieprasījumu ierobežošana novērš ļaunprātīgu izmantošanu. Ievades validācija novērš injekciju uzbrukumus. Audita žurnāli ļauj atklāt un reaģēt.
Katrs no šiem pīlāriem stiprina pārējos. Pieprasījumu ierobežošana pasargā autentifikācijas galapunktus no pārlases uzbrukumiem. Audita žurnāli atklāj modeļus, ko ierobežošana viena pati nenoķer. Ievades validācija novērš uzbrukumus, ko varētu mēģināt autentificēti lietotāji. Kopā tie veido drošības stāvokli, kas ir patiesi noturīgs, nevis tikai formāli atbilstošs.
Ja būvējat API, kas apstrādā sensitīvus datus vai apkalpo uzņēmumu klientus, ieguldiet šajos pamatos laikus. Drošības iestrādāšana jau strādājošā produkcijas API izmaksā par kārtu vairāk nekā tās iebūvēšana no paša sākuma.