لیک شدہ API کلید کو کیسے ٹھیک کیا جائے: گٹ سیکیورٹی کے لیے ایک ڈویلپر گائیڈ

اس کا تصور کریں۔ آپ دیر سے کام کر رہے ہیں اور آپ کا کوڈ آخر کار کام کر رہا ہے اور GitHub پر جانے کے لیے تیار ہے۔

چلائیں:

git add .
git commit -m "Fix API integration"
git push

چند منٹوں کے بعد، آپ نے کچھ عجیب محسوس کیا۔ API کا استعمال اچانک بڑھ گیا ہے۔ آپ کے پاس غیر متوقع درخواستیں، نئے کلاؤڈ وسائل، یا بلز ہو سکتے ہیں جو توقع سے کہیں زیادہ ہیں۔

پھر آپ اسے تلاش کر سکتے ہیں:

const apiKey = "sk_live_123456789";

آپ کی API کلید آپ کے Git ذخیرہ میں ہے۔

یہ صورت حال دباؤ ہے، لیکن یہ درست ہے.

سب سے اہم قوانین ہیں:

اگر آپ کی API کلید گٹ کے ساتھ مرتکب ہوئی ہے تو فرض کریں کہ اس کی کاپی اور خراب ہو گئی ہے، چاہے آپ اسے فوری طور پر حذف کر دیں۔

فائل کے نئے ورژن سے کلید کو حذف کرنا اس بات کو یقینی نہیں بناتا کہ پرانی کلید محفوظ رہے۔ Git فائلوں کے پچھلے ورژن کو اپنی تاریخ میں رکھتا ہے، اور بے نقاب اسناد کو خودکار سکینرز کے ذریعے بازیافت کیا جا سکتا ہے۔

اس گائیڈ میں آپ سیکھیں گے:

ہم پورے مضمون میں درج ذیل بنیادی ورک فلو کا استعمال کرتے ہیں:

Invalidate → Investigate → Remove → Replace → Prevent

اس سے پہلے کہ ہم سب سے اہم حصے پر پہنچیں: اس کے ساتھ کیا کرنا ہے، آئیے اس سے شروع کریں کہ API کلید اصل میں کیا ہے۔ ابھی چابی بے نقاب ہونے کے بعد۔

API کلید کیا ہے؟

API کیز وہ اسناد ہیں جو آپ کی ایپلیکیشن کو دوسری سروسز کے ساتھ بات چیت کرنے کی اجازت دیتی ہیں۔

مثال کے طور پر، آپ کی ایپلیکیشن رسائی کے لیے API کلید استعمال کر سکتی ہے:

چابیاں ہیں:

const apiKey = "your-real-api-key";

یا یہ کنفیگریشن فائل میں ظاہر ہو سکتا ہے۔

{
  "apiKey": "your-real-api-key",
  "databasePassword": "your-real-password"
}

API کیز کو اکثر کہا جاتا ہے۔ دھبے کیونکہ اس کا مالک ہونا کسی کو بھی درخواستیں کرنے، آپ کے ڈیٹا تک رسائی، وسائل بنانے اور آپ کے اکاؤنٹ سے چارج کرنے کی اجازت دیتا ہے۔

تمام API کیز یکساں طور پر حساس نہیں ہیں۔ کچھ خدمات براؤزر کی چابیاں فراہم کرتی ہیں جو صارف کو جان بوجھ کر نظر آتی ہیں۔ ان کلیدوں میں اب بھی مناسب حدود، کوٹے اور اجازتیں ہونی چاہئیں۔

یہ عام طور پر اس طرح ہے:

اگر اسناد ذاتی ڈیٹا تک رسائی حاصل کر سکتے ہیں، وسائل تخلیق کر سکتے ہیں، ریکارڈ میں ترمیم کر سکتے ہیں، یا چارجز تیار کر سکتے ہیں، تو انہیں براہ راست سورس کوڈ میں محفوظ نہیں کیا جانا چاہیے۔

ہنگامی جواب: پہلے کیا کرنا ہے۔

لیک ہونے والی اسناد کو دریافت کرتے وقت، عام رد عمل فائل سے کلید کو حذف کرنا اور ایک اور کمٹ کو آگے بڑھانا ہے۔

وہاں شروع نہ کریں۔

آپ کی اولین ترجیح ہے۔ لیک شدہ اسناد کو بیکار بنا دیتا ہے۔.

درج ذیل کام کی ترتیب کا استعمال کریں:

1. Invalidate the leaked credential
2. Investigate suspicious activity
3. Remove the secret from your code
4. Replace it with a new credential
5. Clean the Git history if necessary
6. Verify the cleanup
7. Add protections against future leaks

اپنی API کلید کے بارے میں سوچیں جیسے گھر کی چابی کسی مصروف سڑک پر گرا دی گئی ہو۔

اگر کسی نے پہلے ہی فزیکل کلید اٹھا لی ہے، تو کلیدی تصویر کو حذف کرنے سے کوئی فرق نہیں پڑتا۔

پہلے اپنے تالے تبدیل کریں۔

مرحلہ 1: لیک شدہ کیز کو کالعدم یا گھمائیں۔

اس سروس کے ڈیش بورڈ پر جائیں جس نے آپ کی اسناد جاری کی ہیں۔

آپ کے فراہم کنندہ پر منحصر ہے، آپ یہ اختیارات دیکھ سکتے ہیں:

منسوخی
حذف کریں
غیر فعال
گردش
دوبارہ پیدا کرنا
ایک نئی کلید بنائیں

اگر آپ کا فراہم کنندہ کلیدی گردش کی حمایت کرتا ہے، اگر ممکن ہو تو، پرانے کو غیر فعال کرنے سے پہلے متبادل اسناد بنائیں۔ کنفیگریشن کو اپ ڈیٹ کرتے وقت یہ ایپلیکیشن ڈاؤن ٹائم کو کم کر سکتا ہے۔

اہم بات یہ ہے کہ آپ کی اصل اسناد اب دستیاب نہیں ہیں۔

لیک شدہ چابیاں دوبارہ استعمال نہ کریں۔ برائے مہربانی نام تبدیل نہ کریں۔ انکوڈ نہ کریں۔ اسے کسی دوسری فائل میں مت منتقل کریں اور فرض کریں کہ یہ محفوظ ہے۔ یہ مت سمجھو کہ اسے کسی نے نہیں دیکھا۔

نقصان پہنچا کے طور پر علاج کریں.

مرحلہ 2: مشکوک سرگرمی کی چھان بین کریں۔

اپنی اسناد کو غیر فعال کرنے کے بعد، اپنے فراہم کنندہ کے استعمال کا ڈیش بورڈ اور لاگز چیک کریں۔

اس طرح کچھ تلاش کریں:

درخواستوں میں اچانک اضافہ
غیر مانوس جگہوں سے درخواستیں۔
غیر متوقع ڈیٹا بیس استفسار
نئے کلاؤڈ وسائل
اجازتیں تبدیل کریں۔
غیر متوقع ڈاؤن لوڈ
غیر معمولی ادائیگی کی سرگرمی
نئی تقسیم
درخواست غیر فعال ہونے پر

اگر کسی سند میں وسیع مراعات ہیں، تو اس استحقاق کے دائرہ کار میں موجود ہر چیز ہے۔ ہو سکتا ہے اس تک رسائی یا ترمیم کی گئی ہو۔.

مثال کے طور پر، اگر آپ اپنے کلاؤڈ اسناد کے ساتھ ایک ورچوئل مشین بنا سکتے ہیں، تو یہ دیکھنے کے لیے چیک کریں کہ آیا کوئی غیر متوقع مشین بنائی گئی تھی۔

اگر آپ کے اسناد کو ڈیٹا بیس تک رسائی حاصل ہے تو درج ذیل کا جائزہ لیں:

توثیق لاگ
آپریشن پڑھیں
آپریشن لکھنا
حذف شدہ تاریخ
برآمد شدہ ڈیٹا
نیا بنایا گیا اکاؤنٹ
اجازتیں تبدیل کریں۔

اپنی بلنگ کی معلومات بھی چیک کریں اگر آپ کی اسناد استعمال پر مبنی چارجز پیدا کر سکتی ہیں۔

آپ نے جو دریافت کیا ہے اسے لکھیں۔ ایک سادہ ٹائم لائن مدد کر سکتی ہے۔

10:15 - API key committed
10:23 - Repository pushed publicly
10:41 - Unusual usage detected
10:45 - Key revoked
11:00 - Logs reviewed
11:30 - Replacement key deployed
12:00 - Git history cleaned

یہ خاص طور پر مفید ہو سکتا ہے اگر آپ کو اپنی ٹیم یا سروس فراہم کنندہ کو کسی واقعے کی اطلاع دینے کی ضرورت ہو۔

مرحلہ 3: موجودہ کوڈ سے راز کو ہٹا دیں۔

ایک بار جب اصل اسناد غیر فعال ہو جائیں تو انہیں ورکنگ فائل سے ہٹا دیں۔

یہ محفوظ نہیں ہے۔

const apiKey = "your-real-api-key";

اس کے بجائے، اپنے ماحول سے اسناد لوڈ کریں۔

const apiKey = process.env.API_KEY;

if (!apiKey) {
  throw new Error("API_KEY is not configured");
}

ازگر میں:

import os

api_key = os.environ.get("API_KEY")

if not api_key:
    raise RuntimeError("API_KEY is not configured")

اہم خیال سادہ ہے.

Source code → environment variable → secret value

بجائے:

Source code → hardcoded secret

ماحولیات کے متغیرات راز کو منظم کرنے کا واحد طریقہ نہیں ہیں، بلکہ یہ مقامی ترقی اور بہت سے تعیناتی ماحول کے لیے ایک عام اور عملی حل ہیں۔

مرحلہ 4: `.env` علاقائی ترقی کے لیے فائلیں

مقامی ترقی کے لیے، ماحولیاتی متغیرات کو سیٹ کریں۔ .env فائل

مثال کے طور پر:

API_KEY=your-local-development-key
DATABASE_URL=your-local-database-url

Node.js پروجیکٹ درج ذیل پیکیجز کا استعمال کرکے ان اقدار کو لوڈ کرسکتے ہیں۔ dotenv.

استعمال کرتے ہوئے انسٹال کریں:

npm install dotenv

پھر:

import "dotenv/config";

const apiKey = process.env.API_KEY;

اہم حصہ ہے۔ .env عام طور پر فائل جمع کروائیں۔ آپ کو گٹ کا عہد نہیں کرنا چاہئے۔.

اسے اگلی بار شامل کریں۔ .gitignore:

# Environment files
.env
.env.*
!.env.example

# Credential files
*.pem
*.key
credentials.json
service-account.json

# Local development files
.DS_Store

لیکن یہاں ایک اہم تفصیل ہے۔ .gitignore یہ ان فائلوں کو نہیں ہٹاتا ہے جن کو Git پہلے ہی ٹریک کر رہا ہے۔

اگر .env یہ پہلے ہی پرعزم ہے، لہذا میں اسے اگلا شامل کروں گا: .gitignore اسے Git میں حذف نہیں کیا گیا ہے۔

جب آپ فائلوں کو اپنے کمپیوٹر پر رکھتے ہیں تو آپ ٹریکنگ روک سکتے ہیں۔

git rm --cached .env

پھر عہد کریں .gitignore تبدیلی:

git add .gitignore
git commit -m "Ignore local environment files"

لیکن یاد رکھیں: یہ صرف مستقبل کے وعدوں سے فائل کو ہٹا دے گا۔ ہاں ~ نہیں سابقہ عہد سے راز کو ہٹا دیں۔

یہ وہ جگہ ہے جہاں گٹ کی تاریخ آتی ہے۔

مرحلہ 5: والٹ بنانا `.env.example`

دوسرے ڈویلپرز کو اب بھی یہ جاننے کی ضرورت ہے کہ ان کی ایپلی کیشن کی ضرورت کے ماحول کے متغیرات کیا ہیں۔

عہد کرنے کی بجائے .envبنانا .env.example:

API_KEY=
DATABASE_URL=
PORT=3000
LOG_LEVEL=info

یہ فائل اصل اسناد کے بجائے متغیر ناموں پر مشتمل ہے، لہذا آپ اسے مخزن میں بھیج سکتے ہیں۔

آپ مندرجہ ذیل رائے بھی دے سکتے ہیں:

# Required API credential
API_KEY=

# PostgreSQL connection string
DATABASE_URL=

# Optional application port
PORT=3000

نیا ڈویلپر پھر فائلوں کو کاپی کر سکتا ہے۔

cp .env.example .env

اور یہ اپنی قدر فراہم کرتا ہے۔

مثال میں واضح طور پر جعلی پلیس ہولڈر کا استعمال کیا گیا ہے۔

API_KEY=replace-me-with-your-own-key

حقیقت پسندانہ نظر آنے والی پیداوار کی اسناد .env.example.

مرحلہ 6: چیک کریں کہ کیا راز اب بھی آپ کی گٹ ہسٹری میں موجود ہے۔

یہ لیک ہونے والی اسناد کو درست کرنے کے سب سے اہم حصوں میں سے ایک ہے۔

فرض کریں کہ آپ کی گٹ ہسٹری اس طرح دکھتی ہے:

Commit A: Add API key to config.js
Commit B: Update API integration
Commit C: Delete API key

اگرچہ کمٹ سی اب کلید پر مشتمل نہیں ہے، کمٹ اے اب بھی کلید پر مشتمل ہے۔

گٹ فائلوں کے پچھلے ورژن کو یاد کرتا ہے۔

آپ فائل کی تاریخ کا استعمال کرتے ہوئے جانچ سکتے ہیں:

git log --all -- config.js

پچھلے وعدوں سے فائلوں کو ظاہر کرنے کے لئے:

git show COMMIT_ID:config.js

آپ گٹ کی سرگزشت کو معلوم لیک اقدار کے لیے بھی تلاش کر سکتے ہیں۔

git log --all -S"your-leaked-key" --oneline

اگر آپ جانتے ہیں کہ ایک راز کا ارتکاب کیا گیا ہے، تو آپ کو فرض کرنا چاہیے کہ یہ ذخیرہ تاریخ میں کہیں موجود ہے جب تک کہ آپ دوسری صورت میں تصدیق نہ کر لیں۔

مجھے اپنی Git کی تاریخ کو کب دوبارہ بنانا چاہئے؟

تمام حادثاتی رازوں کو دوبارہ لکھنے کے ریکارڈ کی ضرورت نہیں ہے۔ مندرجہ ذیل صورت حال پر غور کریں:

راز کا ارتکاب نہیں کیا جاتا

اگر راز صرف ورکنگ ڈائرکٹری میں موجود ہے اور کبھی اس کا ارتکاب نہیں کیا گیا ہے، تو عام طور پر تاریخ کو دوبارہ لکھنے کی ضرورت نہیں ہے۔

اسے ہٹائیں اور مناسب فائلیں شامل کریں۔ .gitignoreاور چلتے رہیں۔

خفیہ مقامی طور پر ارتکاب کیا گیا ہے لیکن دھکا نہیں دیا گیا ہے.

اگر خفیہ مقامی کمٹ میں موجود ہے لیکن اسے ریموٹ ریپوزٹری کے ساتھ شیئر نہیں کیا گیا ہے، تو آپ اس کمٹ کو آگے بڑھانے سے پہلے صاف کر سکتے ہیں۔

راز کو دور دراز کے ذخیرے میں دھکیل دیا گیا ہے۔

اسناد کو سمجھوتہ شدہ سمجھیں۔ فوری طور پر منسوخ کریں یا گھمائیں۔

پھر فیصلہ کریں کہ مخزن کی تاریخ سے راز کو ہٹانا مناسب ہے یا نہیں۔

ذخیرہ جاری کر دیا گیا ہے۔

میں فرض کرتا ہوں کہ کسی نے یا کسی اور چیز نے پہلے ہی راز کو کاپی کر لیا ہے۔

یہی وجہ ہے۔ منسوخی Git کلین اپ سے پہلے آتی ہے۔.

راز ایک نجی ذخیرہ میں تھا۔

نجی ذخیرے عوامی ذخیروں سے زیادہ محفوظ ہیں، لیکن وہ خفیہ نہیں ہیں۔

اسناد کو اب بھی اس کے ذریعے بچایا جا سکتا ہے:

سمجھوتہ شدہ اکاؤنٹ
ٹھیکیدار
انضمام
سی آئی لاگ
کانٹا
بیک اپ
اسکرین شاٹ
کاپی شدہ کوڈ
کھینچنے کی درخواست

تو سب سے محفوظ اصول یہ ہے:

کبھی بھی جان بوجھ کر Git سے اسناد کا ارتکاب نہ کریں، یہاں تک کہ نجی ذخیروں میں بھی۔

مرحلہ 7: گٹ کی تاریخ سے راز کو ہٹا دیں۔

اگر آپ کی اسناد کا ارتکاب کیا گیا ہے، تو آپ کو انہیں ذخیرہ کی تاریخ سے ہٹانے کی ضرورت پڑسکتی ہے۔

اپنی تاریخ کو دوبارہ لکھنے سے پہلے بیک اپ بنائیں:

git clone --mirror https://github.com/your-username/your-repository.git repository-backup.git

آئینے کے کلون میں شاخیں اور ٹیگ ہوتے ہیں، جو کچھ غلط ہونے کی صورت میں بحالی کے لیے مفید ہیں۔

آپشن 1: پوری فائلوں کو ہٹا دیں۔

اگر آپ کا راز کسی فائل میں اس طرح محفوظ ہے: .envآپ اس فائل کو اپنی پوری تاریخ سے ہٹا سکتے ہیں۔

git filter-repo --path .env --invert-paths

ڈائریکٹری کے اندر فائلوں کے لیے:

git filter-repo --path config/production.json --invert-paths

یہ فائل کو ریپوزٹری کی دوبارہ لکھی گئی تاریخ سے ہٹا دے گا۔

آپشن 2: فائلوں کے اندر موجود رازوں کو تبدیل کرنا

بعض اوقات آپ کو فائل رکھنے کی ضرورت ہوتی ہے لیکن خفیہ کے پچھلے ورژن کو ہٹانا پڑتا ہے۔

ایک عارضی متبادل فائل بنائیں۔

پھر چلائیں:

git filter-repo --replace-text replacements.txt

آپ پلیس ہولڈرز کے ساتھ اقدار کی جگہ لے سکتے ہیں۔

your-leaked-key==>YOUR_API_KEY_HERE

بہت محتاط رہیں replacements.txt. کیونکہ اس میں اصل راز موجود ہے۔ اس کا ارتکاب نہ کریں۔

اسے صاف کریں اور اسے حذف کریں۔

rm replacements.txt

ونڈوز پاور شیل میں:

Remove-Item replacements.txt

اگر آپ کے پاس متعدد راز ہیں:

old-api-key==>REMOVED_API_KEY
old-database-password==>REMOVED_DATABASE_PASSWORD
old-token==>REMOVED_TOKEN

پھر:

git filter-repo --replace-text replacements.txt

پہلے بیک اپ کلون پر صفائی کی جانچ کریں۔

مرحلہ 8: یقینی بنائیں کہ آپ کا راز چلا گیا ہے۔

یہ مت سمجھو کہ صفائی نے کام کیا کیونکہ کمانڈ کامیابی سے مکمل ہوگئی۔

معلوم آؤٹ فلو اقدار کے لیے دوبارہ تلاش کریں۔

git log --all -S"your-leaked-key" --oneline

آپ متعلقہ فائلوں اور کمٹ کا بھی معائنہ کر سکتے ہیں۔

git log --all -- config.js

اور:

git show COMMIT_ID:config.js

اگر آپ کا ذخیرہ برانچز اور ٹیگز استعمال کرتا ہے، تو یقینی بنائیں کہ آپ نہ صرف اس برانچ کو چیک کر رہے ہیں جسے آپ نے فی الحال چیک کیا ہے۔

آپ کو دوسرے مقامات کا بھی معائنہ کرنا چاہیے جہاں راز ظاہر ہو سکتے ہیں، بشمول پل کی درخواستیں، CI/CD لاگز، تعمیراتی نمونے، ریلیز فائلز، ڈاکر امیجز، پیکیج ریلیز، دستاویزات، مسئلے کی تفصیل، اور اسکرین شاٹس۔

یاد رکھیں:

ریپوزٹری کو دوبارہ بنانے سے وہ کاپیاں نہیں مٹیں گی جو پہلے سے کہیں اور موجود ہیں۔

یہ آپ کی اصل اسناد کو منسوخ کرنے کی ایک اور وجہ ہے۔

مرحلہ 9: منظم ریکارڈ کو احتیاط سے آگے بڑھائیں۔

صفائی کی تصدیق کرنے کے بعد، آپ کو دوبارہ لکھی گئی تاریخ کو آگے بڑھانے کی ضرورت پڑ سکتی ہے۔

git push --force --all origin
git push --force --tags origin

اہم انتباہ

ریکارڈز کو زبردستی دوبارہ لکھنا تباہ کن ہے۔ یہ کمٹ ہیش کو تبدیل کرتا ہے اور ان تعاون کاروں کو متاثر کر سکتا ہے جن کے پاس ریپوزٹری کی موجودہ نقلیں ہیں۔

مشترکہ منصوبے میں ایسا کرنے سے پہلے:

اپنے ساتھیوں کو بتائیں۔
اس بات کو یقینی بنائیں کہ ہر کوئی یہ سمجھے کہ تاریخ دوبارہ لکھی جا رہی ہے۔
کوآرڈینیٹ صفائی.
اگر آپ کی تنظیم میں واقعہ کے ردعمل کا عمل ہے، تو اس پر عمل کریں۔

دوبارہ تعمیر کرنے کے بعد، تعاون کرنے والوں کو دوبارہ ذخیرہ کو کلون کرنے کی ضرورت پڑ سکتی ہے۔

git clone https://github.com/your-username/your-repository.git

پرانے ذخیرے کی تاریخ کو آنکھیں بند کرکے صاف شدہ ذخیرہ میں ضم نہیں کیا جانا چاہئے۔

مرحلہ 10: کسی بھی جگہ سے اسناد کو تبدیل کریں۔

اب متبادل اسناد بنائیں یا استعمال کریں۔ ان تمام ماحول کو اپ ڈیٹ کریں جہاں آپ کی درخواست چلتی ہے۔ عام مقامات میں شامل ہیں:

مقامی ترقی
ٹیسٹ
ڈرامہ کاری
پیداوار
ڈاکر کنٹینر
Kubernetes راز
CI/CD سسٹم
ہوسٹنگ پلیٹ فارم
طے شدہ کام
سرور کے بغیر افعال

ایک عام غلطی پیداوار کو اپ ڈیٹ کرنا لیکن تعیناتی پائپ لائن کو بھول جانا ہے۔

مثال کے طور پر، مقامی ایپلیکیشنز کام کر سکتی ہیں کیونکہ: .env CI/CD سسٹم میں اب بھی پرانی چابیاں ہیں، لیکن نئی کے ساتھ۔

ایک چیک لسٹ بنائیں:

1. Local development
2. Automated tests
3. Staging
4. Production
5. CI/CD variables
6. Docker configuration
7. Cloud deployment settings
8. Scheduled scripts
9. Serverless functions

اپنی اسناد کو اپ ڈیٹ کرنے کے بعد، ہر حساس ماحول میں اپنی درخواست کی جانچ کریں۔

مرحلہ 11: تبدیلی کی چابیاں محدود کریں۔

لیک شدہ اسناد کو تبدیل کرنا حل کا صرف ایک حصہ ہے۔

آپ کی نئی اسناد میں یہ ہونا ضروری ہے: صرف وہ اجازتیں جو آپ کو درکار ہیں۔.

مفید پابندیوں میں شامل ہیں:

مثال کے طور پر، موسم کی درخواست کو صرف موسم کا ڈیٹا پڑھنے کے لیے اجازت درکار ہو سکتی ہے۔

صارفین کو منظم کرنے، بلنگ میں ترمیم کرنے، یا بیرونی وسائل کو حذف کرنے کی اجازت نہیں ہونی چاہیے۔

یہ ہے کم سے کم استحقاق کا اصول:

ہر ایک سند کو اس کے کام کو انجام دینے کے لیے درکار رسائی کی کم از کم مقدار دیں۔

مختلف ماحول کے لیے مختلف اسناد کا استعمال کرنا بھی اچھا خیال ہے۔

local-development-key
testing-key
staging-key
production-key

یہ آپ کے پیداواری وسائل کو ترقیاتی اسناد کے لیک ہونے کی وجہ سے خود بخود بے نقاب ہونے سے روک دے گا۔

فرنٹ اینڈ ایپلی کیشنز کے بارے میں کیا خیال ہے؟

یہ وہ جگہ ہے جہاں API کلیدی سیکیورٹی الجھن میں پڑ جاتی ہے۔

فرنٹ اینڈ کوڈ صارف کے آلے پر چلتا ہے۔

اس کا مطلب ہے کہ صارفین اس کا معائنہ کر سکتے ہیں۔

مثال کے طور پر:

const apiKey = "browser-key";

صارفین JavaScript بنڈلز، براؤزر ڈویلپر ٹولز، یا نیٹ ورک کی درخواستوں کا معائنہ کر سکتے ہیں اور ممکنہ طور پر اقدار کی جانچ کر سکتے ہیں۔

کچھ سروسز جان بوجھ کر براؤزر API کیز فراہم کرتی ہیں جو عوامی طور پر نظر آنے کے لیے ڈیزائن کی گئی ہیں۔

یہ کلیدیں اب بھی درج ذیل تک محدود ہونی چاہئیں:

وائٹ لسٹ شدہ ڈومین
ویب سائٹ کا ذریعہ
API آپریشنز
استعمال کوٹہ
ریفرر پابندیاں
وقت کی حد

لیکن حقیقی ذاتی اسناد ہیں۔ براؤزر کوڈ میں نہیں رکھا گیا ہے۔.

بجائے:

fetch("https://private-api.example.com/data", {
  headers: {
    Authorization: "Bearer private-secret-token"
  }
});

براؤزر کو اپنا بیک اینڈ کال کرنے دیں۔

fetch("/api/data");

پسدید پھر نجی سروس کے ساتھ بات چیت کرتا ہے۔

const response = await fetch(
  "https://private-api.example.com/data",
  {
    headers: {
      Authorization: `Bearer ${process.env.PRIVATE_API_TOKEN}`
    }
  }
);

اس کے بعد بیک اینڈ صرف وہی معلومات واپس کر سکتا ہے جو براؤزر کو حاصل کرنے کی اجازت ہے۔

اہم اختلافات یہ ہیں:

Public/browser credential
        ↓
Can be visible, but should be restricted

Private credential
        ↓
Must remain on a trusted backend or secret-management system

ماحولیاتی متغیرات اور خفیہ مینیجر

ماحولیاتی متغیرات کارآمد ہیں، لیکن وہ عالمی رازوں کے انتظام کا حل نہیں ہیں۔

چھوٹی ایپلی کیشنز یا مقامی ترقیاتی ماحول کے لیے:

API_KEY=your-secret

یہ بالکل معقول ہو سکتا ہے۔

بڑے پیمانے پر پیداواری نظام کے لیے، سرشار نظاموں کی ضرورت ہو سکتی ہے۔ خفیہ مینیجر.

خفیہ انتظام کے نظام درج ذیل خصوصیات فراہم کر سکتے ہیں:

مرکزی اسناد کا ذخیرہ
رسائی کنٹرول
شکریہ
اسنادی گردش
ورژن کنٹرول
ماحول کے درمیان علیحدگی
تقسیم کے نظام کے ساتھ انضمام

اہم خیال یہ ہے کہ ماخذ کوڈ پیداوار کے راز کو ذخیرہ کرنے کے لیے ذمہ دار نہیں ہونا چاہیے۔

اس کے بجائے:

Application
    ↓
Secret management system
    ↓
Credential

بجائے:

Application
    ↓
Hardcoded production credential

آپ جو حل استعمال کرتے ہیں اس کا انحصار آپ کے پروجیکٹ کے سائز اور ضروریات پر ہوگا۔

اپنے ورک فلو میں خفیہ تلاش شامل کریں۔

انسان عظیم پروگرامر ہیں، لیکن بعض اوقات ہم خوفناک سرچ انجن ہوتے ہیں۔

خودکار خفیہ بازیافت آپ کو اسناد کو اپنے ذخیرہ میں بنائے جانے سے پہلے پکڑنے کی اجازت دیتی ہے۔

کچھ مشہور ٹولز میں شامل ہیں:

مثال کے طور پر، آپ Gitleaks کو مقامی طور پر چلا سکتے ہیں۔

gitleaks detect --source . --verbose

خفیہ سکیننگ کو بھی CI میں ضم کیا جا سکتا ہے۔

بنیادی GitHub ایکشن ورک فلو مندرجہ ذیل ہے:

name: Secret Scan

on:
  push:
  pull_request:

jobs:
  scan:
    runs-on: ubuntu-latest

    steps:
      - name: Check out repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Scan for secrets
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

اپنے پروجیکٹ کے حفاظتی طریقوں کی بنیاد پر اپنے منتخب کردہ ٹول اور فکسڈ ورژن کے لیے دستاویزات کا جائزہ لیں۔

خفیہ اسکینرز غلط مثبت پیدا کر سکتے ہیں، لہذا آپ کو محفوظ ٹیسٹ اقدار کے لیے مستثنیات کو ترتیب دینے کی ضرورت پڑ سکتی ہے۔

لیکن وائٹ لسٹنگ کے بارے میں محتاط رہیں۔ حد سے زیادہ وسیع مستثنیات آپ کی حقیقی اسناد کو چھپا سکتے ہیں۔

آپ فائلوں کے ارتکاب ہونے سے پہلے بھی بازیافت کرسکتے ہیں۔

مثال کے طور پر، ایک سادہ پری کمٹ اسکرپٹ مشکوک الفاظ کو تلاش کر سکتی ہے۔

#!/usr/bin/env bash

if grep -RniE "api[_-]?key|password|secret|token|private[_-]?key" . \
  --exclude-dir=.git \
  --exclude=".env.example"; then

  echo "Possible secret detected. Commit cancelled."
  exit 1
fi

یہ ایک مکمل سیکیورٹی اسکینر نہیں ہے، لیکن یہ واضح غلطیوں کو پکڑ سکتا ہے۔

مضبوط تحفظ کے لیے، پری کمٹ فریم ورک کے ذریعے ایک سرشار خفیہ بازیافت کا آلہ استعمال کریں۔

مقصد ارتکاب کو دکھی بنانا نہیں ہے۔ مقصد یہ ہے کہ حادثاتی طور پر اسناد شائع کرنا مزید مشکل ہو جائے۔

ارتکاب کرنے سے پہلے مرحلہ وار فرق کا جائزہ لیں۔

ایک آسان ترین حفاظتی عادات جو آپ تیار کر سکتے ہیں یہ چیک کرنا ہے کہ آپ اصل میں کیا کرنا چاہتے ہیں۔

پہلا:

git status

پھر صرف وہی فائلیں تیار کریں جو آپ کرنا چاہتے ہیں۔

git add src/api.js README.md

اب مرحلہ وار تبدیلیوں کا جائزہ لیں۔

git diff --cached

تلاش کریں:

API کلید
پاس ورڈ
ٹوکن
نجی URL
اندرونی میزبان نام
کسٹمر ڈیٹا
ڈیبگ آؤٹ پٹ
ذاتی معلومات
ذاتی سرٹیفکیٹ

مرحلہ وار فرق صحیح طریقے سے ظاہر ہونے کے بعد ہی کمٹ کریں۔

git commit -m "Load API key from environment"

براہ کرم درج ذیل کو نوٹ کریں:

git add .

آپ ایسی فائلیں تیار کر سکتے ہیں جنہیں آپ نے کبھی شائع کرنے کا ارادہ نہیں کیا تھا، بشمول: .env فائل، ڈیٹا بیس ایکسپورٹ، جنریٹڈ فائل یا لوکل کنفیگریشن۔

عام غلطیاں جو ڈویلپرز کرتے ہیں۔

غلطی 1: "میں نے اسے مٹا دیا تو یہ ٹھیک ہے”

کسی فائل کے موجودہ ورژن سے کسی راز کو حذف کرنا اسے Git کی تاریخ سے حذف نہیں کرتا ہے۔

جواب: اگر مناسب ہو تو، اسناد کو منسوخ کریں اور ذخیرہ کی تاریخ کو صاف کریں۔

غلطی 2: "ذخیرہ نجی ہے”

ایک نجی ذخیرہ ذخیرہ نہیں ہے۔

سمجھوتہ شدہ اکاؤنٹس، انٹیگریشنز، CI لاگز، فورک، بیک اپ، یا کاپی شدہ کوڈ کے ذریعے اسناد کا لیک ہونا جاری رہ سکتا ہے۔

جواب: پرائیویٹ ریپوزٹریوں میں بھی رازوں کا ارتکاب نہ کریں۔

غلطی 3: "میں اسے صرف انکوڈ کروں گا”

یہ آپ کی اسناد کو خفیہ نہیں بناتا ہے۔

const key = atob("c29tZS1rZXk=");

یا:

const key = "some-" + "secret-" + "value";

یہاں تک کہ اگر آپ انکوڈ کرتے ہیں، تقسیم کرتے ہیں، نام تبدیل کرتے ہیں، یا اپنی اسناد کو چھپاتے ہیں، تب بھی وہ محفوظ نہیں ہیں۔

اگر آپ کی درخواست اپنے اسناد کو دوبارہ تشکیل دے سکتی ہے، تو کوئی آپ کی درخواست کا تجزیہ کرنے والا بھی ایسا ہی کر سکتا ہے۔

غلطی 4: خفیہ ریکارڈ

براہ کرم درج ذیل کام نہ کریں:

console.log(process.env.API_KEY);

لاگز کو ٹرمینلز، CI سسٹمز، ہوسٹنگ پرووائیڈرز، مانیٹرنگ پلیٹ فارمز یا کلاؤڈ سروسز کے ذریعے محفوظ کیا جا سکتا ہے۔

اس کے بجائے:

console.log(
  "API key configured:",
  Boolean(process.env.API_KEY)
);

اگر آپ کو ڈیبگنگ کے دوران اقدار کا معائنہ کرنا ہوگا، تو مکمل اسناد پرنٹ نہ کریں۔

مثال کے طور پر:

function maskSecret(value) {
  if (!value) return "not configured";
  if (value.length <= 8) return "********";

  return `${value.slice(0, 4)}...${value.slice(-4)}`;
}

console.log(maskSecret(process.env.API_KEY));

نقاب پوش اسناد کو بھی احتیاط کے ساتھ سنبھالنا چاہئے۔

غلطی 5: ہر جگہ ایک جیسی اسناد استعمال کریں۔

اگر مقامی ترقی، جانچ، سٹیجنگ، اور پروڈکشن سبھی ایک جیسے اسناد کا استعمال کرتے ہیں، تو ایک خلاف ورزی ان سب کو متاثر کر سکتی ہے۔

جواب: علیحدہ اجازت کے ساتھ علیحدہ اسناد استعمال کریں۔

غلطی 6: صرف موجودہ شاخ کو صاف کرنا

راز اس میں رہ سکتے ہیں:

پرانی شاخ
ٹیگ
کھینچنے کی درخواست
دوسرے حوالہ جات

جواب: لیک شدہ اسناد کی چھان بین اور صفائی کرتے وقت، اپنے پورے ذخیرہ پر غور کریں۔

غلطی 7: نمونے کی تعمیر کو بھول جانا

راز درج ذیل مقامات پر بھی ظاہر ہو سکتے ہیں۔

جواب: اسناد کو منسوخ کریں اور متاثرہ نمونے کی شناخت کریں جنہیں ہٹانے یا تبدیل کرنے کی ضرورت پڑسکتی ہے۔

مکمل API کلیدی واقعہ چیک لسٹ

اگر آپ کو پتہ چلتا ہے کہ آپ کی API کلید سامنے آ گئی ہے، تو درج ذیل چیک لسٹ استعمال کریں:

1. Revoke or rotate the leaked key
2. Create a replacement credential
3. Restrict the replacement credential
4. Review provider logs
5. Review billing and usage
6. Check for unauthorized resources
7. Remove the key from current files
8. Add secret files to .gitignore
9. Create or update .env.example
10. Search Git history
11. Check branches and tags
12. Remove the secret from Git history if necessary
13. Verify the old secret is gone
14. Force-push cleaned history if appropriate
15. Check pull requests and forks
16. Check CI and deployment logs
17. Update local configuration
18. Update staging configuration
19. Update production configuration
20. Update CI/CD secrets
21. Run a secret scanner
22. Document the incident
23. Add preventive security checks

فراہم کنندہ اور پروجیکٹ کے لحاظ سے درست اقدامات مختلف ہوں گے، لیکن آرڈر اہم ہے۔ پہلے اسے باطل کریں۔ اسے دوسری بار صاف کریں۔

محفوظ پروجیکٹ کا ڈھانچہ

یہاں ایک سادہ Node.js پروجیکٹ ہے:

my-project/
├── src/
│   └── api.js
├── .env
├── .env.example
├── .gitignore
├── package.json
└── README.md

علاقہ .env فائل میں حقیقی ترقی کی اقدار شامل ہیں۔

API_KEY=your-local-key

کہ .env.example فائل میں کوئی حقیقی اسناد نہیں ہیں:

API_KEY=replace-me-with-your-own-key

ایپلیکیشن ماحولیاتی متغیرات کو پڑھتی ہے۔

import "dotenv/config";

const apiKey = process.env.API_KEY;

if (!apiKey) {
  throw new Error("Missing API_KEY environment variable");
}

export async function getData() {
  const response = await fetch(
    "https://api.example.com/data",
    {
      headers: {
        Authorization: `Bearer ${apiKey}`
      }
    }
  );

  if (!response.ok) {
    throw new Error(
      `API request failed: ${response.status}`
    );
  }

  return response.json();
}

اور .gitignore مستقبل کے وعدوں میں مقامی ماحول کی فائلوں کو محفوظ کریں۔

.env
.env.*
!.env.example

node_modules/

آخر میں، ایک README آپ کی اسناد کو ظاہر کیے بغیر آپ کے سیٹ اپ کی وضاحت کر سکتا ہے۔

مرحلہ 1: مثال کے ماحول کی فائل کو Bash میں کاپی کریں۔ cp .env.example .env

مرحلہ 2: اپنی خود کی API کلید اس میں شامل کریں: .env.

اور آخری لیکن کم از کم، اپنی درخواست شروع کریں!

npm start

حتمی خیالات

آپ کی API کلید کے لیک ہونے کا مطلب یہ نہیں ہے کہ آپ خراب ڈویلپر ہیں۔ اس کا مطلب ہے کہ آپ کے ڈیولپمنٹ ورک فلو کو بہتر گارڈریلز کی ضرورت ہے۔

اہم بات یہ جاننا ہے کہ کس طرح فوری رد عمل ظاہر کیا جائے اور اسی غلطی کو دوبارہ ہونے سے کیسے روکا جائے۔

ہنگامی فارمولہ یاد رکھیں:

Invalidate → Investigate → Remove → Replace → Prevent

اہم بات یہ جاننا ہے کہ کس طرح فوری رد عمل ظاہر کیا جائے اور اسی غلطی کو دوبارہ ہونے سے کیسے روکا جائے۔

لیک شدہ اسناد کو باطل کریں تاکہ وہ مزید استعمال نہ ہو سکیں۔
غلط استعمال کی جانچ کرنے کے لیے لاگز، استعمال اور بلنگ کی تاریخ کا جائزہ لیں۔
اگر ضروری ہو تو اپنے موجودہ کوڈ اور گٹ ہسٹری سے راز کو ہٹا دیں۔
انہیں نئی اسناد سے تبدیل کریں جن کے پاس صرف ضروری اجازتیں ہیں۔
ماحولیاتی متغیرات، خفیہ مینیجرز، خفیہ اسکیننگ، اور محتاط گٹ پریکٹسز کے ذریعے مستقبل میں لیکس کو روکیں۔

گٹ کسی پروجیکٹ کی تاریخ کو یاد رکھنے میں بہت اچھا ہے۔ یہ اس وقت مفید ہوتا ہے جب آپ غلطی سے کوئی اہم خصوصیت حذف کر دیتے ہیں۔ تاہم، اگر آپ کے ریکارڈ میں پاس ورڈ موجود ہیں، تو وہ بہت کم مفید ہیں۔

لہذا جب مناسب ہو اپنے کوڈ کو عوامی رکھیں۔ اور اپنے راز کہیں اور رکھیں۔

مبارک کوڈنگ!

API کلید کیا ہے؟

ہنگامی جواب: پہلے کیا کرنا ہے۔

مرحلہ 1: لیک شدہ کیز کو کالعدم یا گھمائیں۔

مرحلہ 2: مشکوک سرگرمی کی چھان بین کریں۔

مرحلہ 3: موجودہ کوڈ سے راز کو ہٹا دیں۔

مرحلہ 4: .env علاقائی ترقی کے لیے فائلیں

مرحلہ 5: والٹ بنانا .env.example

مرحلہ 6: چیک کریں کہ کیا راز اب بھی آپ کی گٹ ہسٹری میں موجود ہے۔

مجھے اپنی Git کی تاریخ کو کب دوبارہ بنانا چاہئے؟

راز کا ارتکاب نہیں کیا جاتا

خفیہ مقامی طور پر ارتکاب کیا گیا ہے لیکن دھکا نہیں دیا گیا ہے.

راز کو دور دراز کے ذخیرے میں دھکیل دیا گیا ہے۔

ذخیرہ جاری کر دیا گیا ہے۔

راز ایک نجی ذخیرہ میں تھا۔

مرحلہ 7: گٹ کی تاریخ سے راز کو ہٹا دیں۔

آپشن 1: پوری فائلوں کو ہٹا دیں۔

آپشن 2: فائلوں کے اندر موجود رازوں کو تبدیل کرنا

مرحلہ 8: یقینی بنائیں کہ آپ کا راز چلا گیا ہے۔

مرحلہ 9: منظم ریکارڈ کو احتیاط سے آگے بڑھائیں۔

اہم انتباہ

مرحلہ 10: کسی بھی جگہ سے اسناد کو تبدیل کریں۔

مرحلہ 11: تبدیلی کی چابیاں محدود کریں۔

فرنٹ اینڈ ایپلی کیشنز کے بارے میں کیا خیال ہے؟

ماحولیاتی متغیرات اور خفیہ مینیجر

اپنے ورک فلو میں خفیہ تلاش شامل کریں۔

ارتکاب کرنے سے پہلے مرحلہ وار فرق کا جائزہ لیں۔

عام غلطیاں جو ڈویلپرز کرتے ہیں۔

غلطی 1: "میں نے اسے مٹا دیا تو یہ ٹھیک ہے”

غلطی 2: "ذخیرہ نجی ہے”

غلطی 3: "میں اسے صرف انکوڈ کروں گا”

غلطی 4: خفیہ ریکارڈ

غلطی 5: ہر جگہ ایک جیسی اسناد استعمال کریں۔

غلطی 6: صرف موجودہ شاخ کو صاف کرنا

غلطی 7: نمونے کی تعمیر کو بھول جانا

مکمل API کلیدی واقعہ چیک لسٹ

محفوظ پروجیکٹ کا ڈھانچہ

حتمی خیالات

متعلقہ پوسٹس

مرحلہ 4: `.env` علاقائی ترقی کے لیے فائلیں

مرحلہ 5: والٹ بنانا `.env.example`