Node.js drošības stiprināšana ar TypeScript un Supabase

TypeScript nav tikai "JavaScript ar tipiem". Uzņēmumu kontekstā tā ir drošības stratēģija, kas novērš veselu kļūdu kategoriju pirms kods sasniedz lietotājus. Kombinācijā ar Supabase Row-Level Security un pareizu izvietošanas drošību, TypeScript kļūst par uzņēmuma drošības pamatu.

Kāpēc TypeScript ir svarīgs drošībai

Izpildlaika kļūdu novēršana

Statiskā tipizēšana aptver kļūdas kompilācijas laikā — pirms kodam ir jebkāda iespēja nonākt produkcijā:

• Null/undefined piekļuve — TypeScript strict mode novērš nejaušu null vērtību piekļuvi, kas ir viens no biežākajiem runtime crash iemesliem
• Nepareizi API atbildes formāti — tipizētas API atbildes nodrošina, ka frontend vienmēr sagaida pareizo struktūru
• Trūkstošie lauki — ja datubāzē pieinvieno jaunu lauku, TypeScript kompilators norāda visas vietas, kur kods jāatjaunina
• Nepareizi funkciju argumenti — tipu sistēma nepieļauj nepareizu argumentu padošanu funkcijām

Injekciju novēršana ar tipizētu klientu

Tipizēts Supabase klients ar ģenerētām tipa definīcijām: ```typescript // Supabase CLI ģenerē tipus no datubāzes shēmas import { Database } from './database.types' const supabase = createClient(url, key)

// Tagad vaicājumi ir tipizēti — nevar pieprasīt neeksistējošas kolonnas const { data } = await supabase.from('users').select('id, email, role') // TypeScript brīdinās, ja 'role' kolonna neeksistē datubāzē ```

Drošības ieguvumi vs JavaScript

• 75% mazāk runtime kļūdu — pētījumi rāda, ka TypeScript uztver aptuveni 15% visas JS kļūdas kompilācijā
• Ātrāka kļūdu identificēšana — kļūdas atrod izstrādes laikā, nevis produkcijā
• Refactoring drošība — lielas koda bāzes var droši pārstrukturēt, jo kompilators uztver visas ietekmes

Tipa definīcijas un linting

ESLint drošības noteikumi

ESLint ar drošības spraudņiem automātiski atklāj riskantus koda modeļus:

• eslint-plugin-security — atklāj Object.assign uzbrukumus, eval lietojumu, regex DoS (ReDoS), nesanitizētas ievades
• @typescript-eslint/no-explicit-any — aizliedz any tipu, kas apiET TypeScript drošību
• no-unsafe-assignment — novērš netipizētu vērtību piešķiršanu tipizētiem mainīgajiem
• Sonar drošības noteikumi — SonarQube/SonarCloud integrācija uztver drošības ievainojamības CI pipeline

Tipizēts Supabase klients

```bash # Ģenerē TypeScript tipus no datubāzes shēmas npx supabase gen types typescript --linked > src/database.types.ts

# Automātiskā ģenerēšana CI pipeline # GitHub Actions izpilda katru reizi, kad mainās migrations ```

Ieguvumi:

• Kompilators brīdina, ja vaicājums atsaucas uz neeksistējošu tabulu vai kolonnu
• Autocomplete IDE vidē — izstrādātājs redz pieejamās kolonnas tieši kodā
• Tipizētas insercijas novērš nepilnīgu datu ierakstīšanu

Zod validācija ievades datiem

```typescript import { z } from 'zod'

const ContactSchema = z.object({ name: z.string().min(2).max(100), email: z.string().email(), message: z.string().min(10).max(5000), phone: z.string().regex(/^\+?[\d\s-]{7,15}$/).optional(), })

// Serverī — validē PIRMS jebkādas datubāzes darbības const result = ContactSchema.safeParse(req.body) if (!result.success) return res.status(400).json(result.error) ```

Datubāzes drošība ar Supabase

RLS (Row-Level Security) padziļināti

RLS politikas ļauj definēt piekļuvi tabulas līmenī — katram vaicājumam tiek piemērotas drošības politikas neatkarīgi no tā, kāds kods veic vaicājumu:

Piemērs — lietotāji redz tikai savus datus: ```sql CREATE POLICY "Users read own data" ON profiles FOR SELECT USING (auth.uid() = user_id);

CREATE POLICY "Users update own data" ON profiles FOR UPDATE USING (auth.uid() = user_id) WITH CHECK (auth.uid() = user_id); ```

Piemērs — admin piekļuve: ```sql CREATE POLICY "Admins full access" ON profiles FOR ALL USING ( EXISTS (SELECT 1 FROM user_roles WHERE user_id = auth.uid() AND role = 'admin') ); ```

Lomu pārvaldība

Supabase piedāvā trīs galvenās lomas:

• anon — neautentificēti lietotāji. Minimālas tiesības — tikai publisks saturs
• authenticated — pieteikušies lietotāji. Piekļuve saviem datiem caur RLS politikām
• service_role — pilna piekļuve, apiet RLS. Lietot TIKAI serverī, NEKAD klientā

PostgREST drošība

Supabase API (PostgREST) automātiski piemēro RLS — nav iespējams apiet drošību caur API manipulācijām, ja RLS ir konfigurēts korekti.

Izvietošanas drošība

Noslēpumu pārvaldība

• Nekad .env failā git — .gitignore vienmēr satur .env*. Pre-commit hooks (husky) bloķē commitus ar noslēpumiem
• Vercel Environment Variables — šifrēti, ar atsevišķiem mainīgajiem development, preview un production vidēm
• Secrets scanning — GitHub Advanced Security, GitGuardian skenē repozitoriju pēc nejaušiem noslēpumiem
• Rotācija — API atslēgas un datubāzes paroles regulāri jāmaina (vismaz reizi ceturksnī)

CORS un rate limiting

```typescript // Next.js middleware rate limiting piemērs const rateLimit = new Map()

export function middleware(req: NextRequest) { const ip = req.ip ?? 'unknown' const now = Date.now() const windowMs = 60_000 // 1 minūte const maxRequests = 30

const record = rateLimit.get(ip) if (record && now - record.timestamp < windowMs) { if (record.count >= maxRequests) { return new NextResponse('Too many requests', { status: 429 }) } record.count++ } else { rateLimit.set(ip, { count: 1, timestamp: now }) } } ```

CSP (Content Security Policy)

Stingra CSP galvene novērš XSS uzbrukumus, ierobežojot, no kurienes pārlūks drīkst ielādēt resursus. Next.js atbalsta CSP konfigurāciju caur next.config.ts vai middleware.

TypeScript + Supabase RLS + pareiza DevOps drošība = daudzlīmeņu aizsardzība, kur katrs slānis aptver to, ko iepriekšējais var palaist garām.