Next.js Server Actions hufichua kiotomatiki kila kazi iliyotolewa (exported function) kwenye faili ya use-server kama endpoint ya umma ya HTTP, ikijipa utambulisho wa kipekee ambao mteja (client) hutumia kuita kazi hiyo. Endpoint hiyo ipo iwe kuna kitufe, kiungo, au kipengele kingine chochote cha UI kilichochorwa (rendered), ikimaanisha kuwa mtu yeyote anayegundua utambulisho huo anaweza kuita kazi hiyo moja kwa moja.
Muundo wa framework hii unachukulia Server Actions kama kazi za msaada (helper functions) za kawaida, lakini wakati wa utendaji (runtime) zinakuwa URL zinazofikiwa. Kwa watengenezaji ambao walidhani kuwa UI ndiyo mlinzi pekee, hii inatengeneza eneo la mashambulizi lisiloonekana ambalo linaweza kutumiwa kwa ombi moja tu lililoundwa kwa makusudi.
Kwa nini Server Actions zilionekana salama
Server Actions zilianzishwa ili kuruhusu watengenezaji kuandika kodi ya upande wa seva (server-side code) karibu kabisa na vipengele (components) vyao, wakiepuka kazi nyingi za ziada (boilerplate) za njia za API tofauti. Matumizi ya kawaida yanaonekana hivi:
<form action={deleteInvoice}>
<button type="submit">Delete</button>
</form>
Kwa sababu fomu ndiyo njia pekee inayoonekana ya kuamsha deleteInvoice, watengenezaji wengi huficha kitufe kwa watumiaji wasio na ruhusa, wakidhani kuwa saini za TypeScript zitazuia data zisizo sahihi, na kutegemea ukweli kwamba kazi hiyo ipo kwenye moduli ya upande wa seva pekee. Hakuna kati ya dhana hizo zinazotoa ulinzi wa kweli.
Ufichuzi uliojificha
Faili linapokuwa na “use server”, Next.js inatafsiri kila kazi iliyotolewa kuwa endpoint kama:
POST /_next/data/<build-id>/<page>.json?__rsc=<action-id>
<action-id> ni hash thabiti ambayo bundle ya mteja (client bundle) huijumuisha. Mshambuliaji anaweza kuipata kwa:
- Kuchunguza trafiki ya mtandao ya ukurasa.
- Kusoma JavaScript iliyojumuishwa (ID ni string ya kawaida).
- Kukisia kulingana na kanuni za majina ikiwa mradi unafuata mifumo inayotabirika.
Mara tu ID inapojulikana, ombi linaweza kutumwa kutoka kwa kifaa chochote—cURL, Postman, au script hasidi—likipita ukaguzi wowote wa kiwango cha UI.
Hatari tatu za wazi
| Hatari | Kwa nini ni muhimu |
|---|---|
| Ukaguzi wa UI haufanyi kazi | Kuficha kitufe au kiungo hakufuti endpoint ya msingi. Endpoint inabaki inafikiwa, kama vile ukurasa wa admin uliofichwa ambao bado upo kwenye seva. |
| TypeScript haitoi usalama wakati wa utendaji | Aina (types) huondolewa kodi inapofanya kazi. Kazi iliyotangazwa kama deleteInvoice(id: number) inaweza kupokea string kubwa, array, au hata JSON hasidi, ikisababisha makosa ya mantiki au mashambulizi ya injection. |
| Hakuna uthibitishaji au ruhusa ya kutosha kwa kuanzia | Server Actions zinaonekana kama kazi za msaada za ndani, hivyo watengenezaji mara nyingi husahau kuongeza ukaguzi wa session, ulinzi wa CSRF, au ukaguzi wa ruhusa za ngazi ya mstari (row-level permission checks) ambazo ni za kawaida katika njia za API za jadi. |
Jinsi ya kulinda Server Action
- Thibitisha msemaji (caller) – Hakikisha kuwa session au token halali ipo kabla ya mantiki yoyote ya biashara kufanya kazi.
- Hakiki payload – Tumia maktaba ya schema (mfano, Zod, Yup) ili kusimamia aina za data na vizuizi vya thamani wakati wa utendaji.
- Toa ruhusa ya operesheni – Zaidi ya "je, mtumiaji ameingia?", thibitisha kuwa mtumiaji anamiliki rekodi mahususi anayojaribu kuibadilisha au kuifuta.
Mfano mdogo:
'use server';
import { getSession } from '@/auth';
import { z } from 'zod';
import { db } from '@/db';
const DeleteInvoiceSchema = z.object({
id: z.number().int().positive(),
});
export async function deleteInvoice(formData: FormData) {
const session = await getSession();
if (!session) throw new Error('Unauthenticated');
const parsed = DeleteInvoiceSchema.safeParse({
id: Number(formData.get('id')),
});
if (!parsed.success) throw new Error('Invalid input');
const invoice = await db.invoice.findUnique({ where: { id: parsed.data.id } });
if (!invoice || invoice.ownerId !== session.userId) {
throw new Error('Unauthorized');
}
await db.invoice.delete({ where: { id: invoice.id } });
}
Kodi hii inathibitisha uthibitishaji (authentication) waziwazi, inahakiki id inayokuja, na kuhakikisha kuwa mtumiaji aliyeingia anamiliki ankara (invoice) hiyo kabla ya kufanya ufutaji.
Changamoto nyingine ndogo za Next.js
| Tatizo | Dalili | Suluhisho |
|---|---|---|
Variable za mazingira za NEXT_PUBLIC_ |
Chochote chenye kiambishi awali cha NEXT_PUBLIC_ huwekwa kwenye bundle ya mteja, kikifichua siri. |
Weka siri kwenye env vars za kawaida, usizipe kiambishi awali cha NEXT_PUBLIC_. |
| Open redirects | Kukubali parameter ya redirect na kuiunganisha bila uangalifu kunaweza kuwatuma watumiaji kwenye //evil.com. |
Hakiki lengo dhidi ya orodha ya kuruhusiwa (whitelist) au simamia ukaguzi wa asili moja (same-origin checks). |
| Server-Side Request Forgery (SSRF) | Kuchukua URL inayotolewa na mtumiaji kunaweza kuwaruhusu washambuliaji kufikia huduma za ndani au endpoint za metadata za wingu. | Ruhusu majina ya host (hostnames), zuia masafa ya IP za ndani, na weka muda wa mwisho (timeouts). |
dangerouslySetInnerHTML |
Kuchora HTML inayotolewa na mtumiaji bila kusafisha (sanitisation) kunafungua XSS. | Tumia maktaba kama DOMPurify au epuka HTML mbichi kabisa. |
Kuskani mifumo hii kiotomatiki
Zana za uchambuzi wa tuli (static-analysis tools) zinaweza kuashiria miundo hatari iliyotajwa hapo juu. Chaguo moja nyepesi ni Semgrep, ambayo hukimbia haraka na inaweza kuunganishwa kwenye mifumo ya CI:
npx --yes semgrep --config https://raw.githubusercontent.com/catidegla/stacksec/main/rules .
Seti ya sheria inajumuisha ukaguzi wa kazi za seva zilizotolewa, matumizi mabaya ya NEXT_PUBLIC_, redirects za wazi, mifumo ya SSRF, na uwekaji wa HTML usio salama.
Nini cha kuangalia baadaye
- Sasisho za Framework – Fuatilia toleo mpya za Next.js; timu inaweza kuanzisha 'authentication hooks' za ndani au kuweka 'sandbox' kwenye 'endpoints' zinazozalishwa.
- Zana za jamii – Viamatishi (plugins) vipya vya ESLint na kanuni za Semgrep mahususi kwa Next.js vinatokea ili kurahisisha kinga zilizoelezwa hapa.
- Matukio ya ulimwengu halisi – Kadri miradi mingi inavyotumia Server Actions, angalia udhaifu (exploits) uliowazi unaoonyesha hatari hiyo katika vitendo. Ugunduzi wa mapema unaweza kusaidia katika mapitio ya usalama ya ndani kabla ya uvunjifu kutokea.
Muhtasari: Next.js Server Action si msaidizi wa siri; ni 'public HTTP endpoint' mara tu unapou-export. Ichuze kama njia nyingine yoyote ya API—thibitisha, hakiki, na ruhusu—vinginevyo urahisi wa kuandika kodi ya seva karibu na UI unaweza kuwa hatari ya usalama haraka sana.