Next.js Server Actions એ use-server ફાઇલમાં એક્સપોર્ટ કરેલા દરેક ફંક્શનને આપમેળે પબ્લિક HTTP એન્ડપોઇન્ટ તરીકે એક્સપોઝ કરે છે, તેને એક યુનિક આઈડેન્ટિફાયર અસાઇન કરે છે જેનો ઉપયોગ ક્લાયન્ટ ફંક્શનને ઇનવોક કરવા માટે કરે છે. બટન, લિંક અથવા અન્ય કોઈ UI એલિમેન્ટ રેન્ડર થાય કે ન થાય, એન્ડપોઇન્ટ અસ્તિત્વ ધરાવે છે, જેનો અર્થ છે કે જે કોઈ પણ આ આઈડેન્ટિફાયર શોધી લે છે તે સીધું જ ફંક્શનને કોલ કરી શકે છે.
ફ્રેમવર્કનું ડિઝાઇન Server Actions ને સામાન્ય હેલ્પર ફંક્શન તરીકે ગણે છે, પરંતુ રનટાઇમમાં તે રિચેબલ (reachable) URL બની જાય છે. જે ડેવલપર્સ એવું માને છે કે UI એ એકમાત્ર ગેટકીપર છે, તેમના માટે આ એક અદ્રશ્ય એટેક સરફેસ બનાવે છે જેનો ઉપયોગ એક જ તૈયાર કરેલા (crafted) રિક્વેસ્ટ દ્વારા કરી શકાય છે.
શા માટે Server Actions સુરક્ષિત લાગતા હતા
ડેવલપર્સને અલગ API રૂટ્સના બોઈલરપ્લેટ (boilerplate) ને ટાળવા માટે તેમના કમ્પોનન્ટ્સની બાજુમાં જ સર્વર-સાઇડ કોડ લખવા દેવા માટે Server Actions રજૂ કરવામાં આવ્યા હતા. એક સામાન્ય ઉપયોગ આ મુજબ દેખાય છે:
<form action={deleteInvoice}>
<button type="submit">Delete</button>
</form>
કારણ કે deleteInvoice ને ટ્રિગર કરવાનો ફોર્મ એ એકમાત્ર દેખીતો રસ્તો છે, ઘણા ડેવલપર્સ અનધિકૃત વપરાશકર્તાઓ માટે બટનને છુપાવી દે છે, એવું વિચારે છે કે TypeScript સિગ્નેચર ખોટી રીતે બનાવેલા ડેટાને અટકાવશે, અને એ હકીકત પર આધાર રાખે છે કે ફંક્શન સર્વર-ઓન્લી મોડ્યુલમાં છે. આમાંથી કોઈ પણ ધારણા વાસ્તવિક સુરક્ષા પૂરી પાડતી નથી.
છુપાયેલું એક્સપોઝર
જ્યારે ફાઇલમાં “use server” હોય છે, ત્યારે Next.js દરેક એક્સપોર્ટ કરેલા ફંક્શનને આ પ્રકારના એન્ડપોઇન્ટમાં કમ્પાઇલ કરે છે:
POST /_next/data/<build-id>/<page>.json?__rsc=<action-id>
<action-id> એ એક સ્ટેબલ હેશ છે જે ક્લાયન્ટ બંડલમાં એમ્બેડ કરવામાં આવે છે. એટેકર તેને આ રીતે મેળવી શકે છે:
- પેજ ટ્રાફિકનું નિરીક્ષણ કરીને (Inspecting the page’s network traffic).
- બંડલ કરેલા JavaScript ને વાંચીને (The ID is a plain string).
- જો પ્રોજેક્ટ અનુમાનિત પેટર્ન અનુસરે છે, તો નામકરણ પદ્ધતિઓ (naming conventions) ના આધારે અનુમાન લગાવીને.
એકવાર ID જાણી લેવામાં આવે, પછી કોઈપણ સાધન—cURL, Postman, અથવા કોઈ માલશિયસ (malicious) સ્ક્રિપ્ટ—સાથેથી રિક્વેસ્ટ મોકલી શકાય છે, જે કોઈપણ UI-લેવલના ચેક્સને બાયપાસ કરી શકે છે.
ત્રણ ચોક્કસ જોખમો
| જોખમ | શા માટે તે મહત્વનું છે |
|---|---|
| UI ચેક્સ બિનઅસરકારક છે | બટન અથવા લિંક છુપાવવાથી અન્ડરલાઇંગ એન્ડપોઇન્ટ ડિલીટ થતું નથી. એન્ડપોઇન્ટ રિચેબલ રહે છે, જેમ કે છુપાયેલું એડમિન પેજ જે હજુ પણ સર્વર પર અસ્તિત્વ ધરાવે છે. |
| TypeScript રનટાઇમ સેફ્ટી આપતું નથી | જ્યારે કોડ રન થાય છે ત્યારે ટાઇપ્સ દૂર કરવામાં આવે છે. deleteInvoice(id: number) તરીકે જાહેર કરાયેલ ફંક્શન વિશાળ સ્ટ્રિંગ, એરે અથવા માલશિયસ JSON પણ મેળવી શકે છે, જે લોજિક એરર્સ અથવા ઇન્જેક્શન એટેક્સ તરફ દોરી શકે છે. |
| કોઈ ડિફોલ્ટ ઓથેન્ટિકેશન અથવા ઓથોરાઈઝેશન નથી | Server Actions લોકલ હેલ્પર જેવા લાગે છે, તેથી ડેવલપર્સ ઘણીવાર સેશન ચેક્સ, CSRF પ્રોટેક્શન અથવા રો-લેવલ પરમિશન ચેક્સ ઉમેરવાનું ભૂલી જાય છે જે પરંપરાગત API રૂટ્સમાં સ્ટાન્ડર્ડ છે. |
Server Action ને કેવી રીતે સુરક્ષિત કરવું
- કોલરને ઓથેન્ટિકેટ કરો (Authenticate the caller) – કોઈપણ બિઝનેસ લોજિક ચાલતા પહેલા વેરિફાય કરો કે માન્ય સેશન અથવા ટોકન અસ્તિત્વ ધરાવે છે.
- પેલોડને વેલિડેટ કરો (Validate the payload) – રનટાઇમમાં ડેટા પ્રકારો અને વેલ્યુ કન્સ્ટ્રેઇન્ટ્સ લાગુ કરવા માટે સ્કીમા લાઇબ્રેરી (દા.ત., Zod, Yup) નો ઉપયોગ કરો.
- ઓપરેશનને ઓથોરાઈઝ કરો (Authorize the operation) – “શું યુઝર લોગિન છે?” તેનાથી આગળ વધીને, ખાતરી કરો કે યુઝર તે ચોક્કસ રેકોર્ડનો માલિક છે જેને તેઓ મોડિફાય અથવા ડિલીટ કરવાનો પ્રયાસ કરી રહ્યા છે.
એક ન્યૂનતમ ઉદાહરણ:
'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 } });
}
આ કોડ સ્પષ્ટપણે ઓથેન્ટિકેશન તપાસે છે, આવતા id ને વેલિડેટ કરે છે, અને ડિલીટ કરવાની પ્રક્રિયા કરતા પહેલા લોગિન કરેલ યુઝર ખરેખર ઇન્વોઇસનો માલિક છે તેની ખાતરી કરે છે.
અન્ય સૂક્ષ્મ Next.js પિಟ್ફોલ્સ
| સમસ્યા | લક્ષણ | ઉકેલ |
|---|---|---|
NEXT_PUBLIC_ એન્વાયરમેન્ટ વેરિયેબલ્સ |
NEXT_PUBLIC_ થી શરૂ થતી કોઈપણ વસ્તુ ક્લાયન્ટમાં બંડલ થાય છે, જે સિક્રેટ્સને એક્સપોઝ કરે છે. |
સિક્રેટ્સને સાદા એન્વાયરમેન્ટ વેરિયેબલ્સમાં રાખો, તેમને ક્યારેય NEXT_PUBLIC_ સાથે પ્રીફિક્સ ન કરો. |
| ઓપન રિડાયરેક્ટ્સ | redirect ક્વેરી પેરામીટર સ્વીકારવો અને તેને સીધો જોડવો (concatenating) યુઝર્સને //evil.com પર મોકલી શકે છે. |
વ્હાઇટલિસ્ટ સામે ટાર્ગેટને વેલિડેટ કરો અથવા સેમ-ઓરિજિન ચેક્સ લાગુ કરો. |
| સર્વર-સાઇડ રિક્વેસ્ટ ફોર્જરી (SSRF) | યુઝર દ્વારા સપ્લાય કરેલ URL ફેચ કરવાથી એટેકર્સ ઇન્ટરનલ સર્વિસીસ અથવા ક્લાઉડ મેટાડેટા એન્ડપોઇન્ટ્સ સુધી પહોંચી શકે છે. | હોસ્ટનેમ્સને એલાઉ-લિસ્ટ કરો, પ્રાઇવેટ IP રેન્જને બ્લોક કરો અને ટાઇમઆઉટ સેટ કરો. |
dangerouslySetInnerHTML |
સેનિટાઇઝેશન વગર યુઝર દ્વારા આપવામાં આવેલ HTML રેન્ડર કરવાથી XSS ખુલે છે. | DOMPurify જેવી લાઇબ્રેરીનો ઉપયોગ કરો અથવા કાચા (raw) HTML ને સંપૂર્ણપણે ટાળો. |
આ પેટર્ન માટે આપમેળે સ્કેનિંગ કરવું
સ્ટેટિક-એનાલિસિસ ટૂલ્સ ઉપર સૂચિબદ્ધ જોખમી કન્સ્ટ્રક્ટ્સને ફ્લેગ કરી શકે છે. એક લાઇટવેઇટ વિકલ્પ Semgrep છે, જે ઝડપથી ચાલે છે અને CI પાઇપલાઇન્સમાં ઇન્ટિગ્રેટ કરી શકાય છે:
npx --yes semgrep --config https://raw.githubusercontent.com/catidegla/stacksec/main/rules .
રૂલ સેટમાં એક્સપોર્ટ કરેલા સર્વર ફંક્શન્સ, NEXT_PUBLIC_ નો દુરુપયોગ, ઓપન રિડાયરેક્ટ્સ, SSRF પેટર્ન અને અસુરક્ષિત HTML ઇન્સર્શન માટેના ચેક્સનો સમાવેશ થાય છે.
આગળ શું જોવું
- ફ્રેમવર્ક અપડેટ્સ – Next.js ના રિલીઝ પર નજર રાખો; ટીમ ઇન-બિલ્ટ authentication hooks રજૂ કરી શકે છે અથવા જનરેટ કરેલા endpoints ને sandbox કરી શકે છે.
- કોમ્યુનિટી ટૂલિંગ – અહીં વર્ણવેલ સુરક્ષાના ઉપાયોને સ્વચાલિત કરવા માટે નવા ESLint plugins અને Next.js-વિશિષ્ટ Semgrep rules ઉભરી રહ્યા છે.
- વાસ્તવિક દુનિયાની ઘટનાઓ – જેમ જેમ વધુ પ્રોજેક્ટ્સ Server Actions અપનાવશે, તેમ જાહેર થયેલા એક્સપ્લોઇટ્સ (exploits) પર નજર રાખો જે વ્યવહારમાં જોખમ દર્શાવે છે. કોઈપણ સુરક્ષા ભંગ (breach) થાય તે પહેલાં વહેલી જાણકારી આંતરિક સુરક્ષા સમીક્ષાઓમાં મદદરૂપ થઈ શકે છે.
મુખ્ય વાત: Next.js Server Action એ કોઈ ખાનગી હેલ્પર નથી; તમે તેને export કરો તે ક્ષણથી તે એક પબ્લિક HTTP endpoint બની જાય છે. તેને અન્ય કોઈપણ API route ની જેમ ગણો—authenticate, validate અને authorize કરો—અન્યથા, UI ની બાજુમાં સર્વર કોડ લખવાની સુવિધા ઝડપથી સુરક્ષા માટે જોખમ (security liability) બની શકે છે.