هاردم‌کد در برنامه‌نویسی: چیست، دلایل و نحوه اجتناب

هاردم‌کد در برنامه‌نویسی چیست

هاردم‌کد (hardcode, hard coding) — یک ضدالگوست که در آن داده‌ها، پارامترهای تنظیمات یا مقادیر کانفیگ مستقیماً در متن برنامه جاسازی می‌شوند. به جای خواندن این داده‌ها از منابع خارجی، توسعه‌دهنده آنها را به صورت لیترال — رشته‌ها، اعداد، مقادیر بولی — مستقیماً در بدنه تابع، کلاس یا ماژول می‌نویسد. این اصطلاح در جامعه توسعه‌دهندگان در دهه 1980 میلادی ظهور کرد، زمانی که نرم‌افزار شروع به گسترش روی پلتفرم‌های سخت‌افزاری مختلف کرد و مشخص شد که پارامترهای سخت‌نویسی شده مانع قابلیت حمل می‌شوند.

مشکل اصلی هاردم‌کد در این است که تغییر هر یک از این مقادیر نیاز به ویرایش کد منبع، کامپایل مجدد و استقرار مجدد برنامه دارد. این روند به‌روزرسانی را کند، مستعد خطا و خطرناک می‌کند — توسعه‌دهنده ممکن است در حین ویرایش یک پارامتر سخت‌نویسی شده، به طور تصادفی چیز دیگری را در کد تغییر دهد. در رویه‌های مدرن DevOps این رویکرد به شدت توصیه نمی‌شود.

بر اساس تحقیق Veracode State of Software Security 2024، حدود 23% از تمام آسیب‌پذیری‌ها در برنامه‌های تجاری با استفاده از داده‌های احراز هویت سخت‌نویسی شده مرتبط است. این امر مبارزه با هاردم‌کد را نه تنها یک مسئله راحتی، بلکه یک وظیفه حیاتی امنیت اطلاعات می‌کند.

تعریف هاردم‌کد به زبان ساده

مقدار سخت‌نویسی شده — هر عدد، رشته یا تنظیماتی است که مستقیماً در کد نوشته شده، نه اینکه از کانفیگ بارگذاری شود. به عنوان مثال، اگر توسعه‌دهنده `connectionTimeout = 30` را در داخل کلاس اتصال به پایگاه داده بنویسد — این هاردم‌کد است. اگر او زمان انتظار را از متغیر محیطی یا فایل کانفیگ بخواند — این رویکرد درستی است.

ریشه اصطلاح

کلمه هاردم‌کد از hard code انگلیسی گرفته شده است — «کد سخت». برخلاف کانفیگ‌های انعطاف‌پذیر، هاردم‌کد به معنای واقعی کلمه در فایل اجرایی «دوخته» شده و بدون بازسازی قابل تغییر نیست.

چرا هاردم‌کد یک رویه مضر محسوب می‌شود

هاردم‌کد مشکلات متعددی در بلندمدت ایجاد می‌کند. اولین و آشکارترین — عدم امکان تغییر رفتار برنامه بدون تغییر کد منبع. دوم — خطر نشت اطلاعات محرمانه. سوم — پیچیده‌تر شدن تست‌گیری، به ویژه تست واحد و یکپارچه‌سازی.

در Agile و DevOps، جایی که استقرار سریع در محیط‌های مختلف — development, staging, production — مورد نیاز است، هاردم‌کد به یک مانع غیرقابل عبور تبدیل می‌شود. تیم مجبور می‌شود قبل از هر استقرار کد را تصحیح کند یا از پچ‌های دستی استفاده کند که با اصول Continuous Delivery در تضاد است.

تحقیق Cambridge University (2023) نشان داد که پروژه‌های با سطح بالای هاردم‌کد 47% نقص‌های بیشتر در انتشار دارند و 2.3 برابر زمان بیشتری برای اعمال تغییرات نیاز دارند. این تأیید می‌کند که هزینه نگهداری کد سخت‌نویسی شده به طور قابل توجهی از صرفه‌جویی وقت در مرحله اولیه توسعه بیشتر است.

مقیاس‌پذیری و قابلیت حمل

برنامه با پارامترهای سخت‌نویسی شده به سختی با پلتفرم‌های مختلف سازگار می‌شود. به عنوان مثال، مسیر فایل `C:\Users\admin\data.txt` روی سرور لینوکس کار نخواهد کرد. و اندازه قلم 14pt ممکن است در دستگاه‌هایی با تراکم پیکسل متفاوت، ظاهر متفاوتی داشته باشد.

قابلیت نگهداری کد

وقتی هاردم‌کد در سراسر پروژه پخش شده است، توسعه‌دهنده باید هر مقدار را به صورت دستی جستجو کند، با استفاده از grep یا جستجوی IDE. این کار توسعه را کند می‌کند، احتمال از دست رفتن مقدار مورد نظر را افزایش می‌دهد و راه را برای باگ‌ها باز می‌کند. علاوه بر این، عضو جدید تیم زمان قابل توجهی بیشتری برای درک «اعداد جادویی» و رشته‌ها صرف می‌کند.

چه مقادیری بیشتر هاردم‌کد می‌شوند

رمزهای عبور و اطلاعات احراز هویت — خطرناک‌ترین نوع هاردم‌کد. توسعه‌دهندگان اغلب رمزهای عبور پایگاه داده، کلیدهای API سرویس‌های شخص ثالث، توکن‌های احراز هویت را مستقیماً در کد برای راحتی توسعه محلی ذخیره می‌کنند، اما فراموش می‌کنند قبل از commit آنها را به کانفیگ منتقل کنند. این منجر به نشت در مخازن عمومی می‌شود.

آدرس‌های URL و endpointهای سرویس‌های خارجی نیز اغلب قربانی هاردم‌کد می‌شوند. هنگام تغییر هاستینگ یا نسخه API، توسعه‌دهنده باید URL را در ده‌ها مکان به‌روزرسانی کند. اگر آدرس در چندین ماژول هاردم‌کد شده باشد، بخشی از لینک‌ها قدیمی می‌ماند و برنامه به درستی کار نمی‌کند.

اعداد جادویی — ثابت‌های عددی بدون توضیح. به عنوان مثال، `price * 0.85` به جای `price * DISCOUNT_RATE`. خواننده کد نمی‌فهمد 0.85 به چه معناست. این یک مثال کلاسیک از هاردم‌کد است که توسط مارتین فاولر در کتاب «رفکتورینگ» (1999) توصیف شده است.

رشته‌های جادویی

لیترال‌های رشته‌ای که در بخش‌های مختلف برنامه تکرار می‌شوند — یکی دیگر از انواع رایج هاردم‌کد. به عنوان مثال، کلیدهای دیکشنری، هدرهای HTTP، نام ویوها در اپلیکیشن iOS. اگر رشته در یک مکان تغییر کند اما در مکان دیگر باقی بماند، برنامه خراب می‌شود. راه حل — انتقال رشته‌ها به ثابت‌ها یا فایل‌های بومی‌سازی.

کانفیگ محیط

حالت‌های کار برنامه (debug/release)، تنظیمات لاگینگ، آدرس‌های سرور SMTP — همه این پارامترها باید خارجی باشند. اگر آنها هاردم‌کد شده باشند، هنگام انتقال به سرور دیگر برنامه ممکن است راه‌اندازی نشود یا رفتار غیرقابل پیش‌بینی داشته باشد.

ریسک‌های امنیتی در استفاده از هاردم‌کد

رمزهای عبور و کلیدهای سخت‌نویسی شده تهدید مستقیمی برای امنیت برنامه هستند. اگر مهاجم به کد منبع دسترسی پیدا کند (از طریق نشت مخزن، فرد داخلی یا دی‌کامپایل)، فوراً به تمام منابع محافظت‌شده دسترسی پیدا می‌کند. در سال 2023، GitHub بیش از 12 میلیون نشت اسرار را در مخازن عمومی کشف کرد.

استاندارد OWASP (Open Web Application Security Project) هاردم‌کد اطلاعات احراز هویت را در رده A04:2021 — Insecure Design قرار می‌دهد. توصیه OWASP — هرگز رمزهای عبور، توکن‌ها یا کلیدها را در کد منبع ذخیره نکنید. به جای آن از سرویس‌های تخصصی مدیریت اسرار استفاده کنید: HashiCorp Vault، AWS Secrets Manager یا Azure Key Vault.

ممیزی امنیتی انجام شده توسط Positive Technologies (2024) نشان داد که 78% از برنامه‌های موبایل آزمایش‌شده حداقل حاوی یک کلید یا توکن سخت‌نویسی شده هستند. در برنامه‌های وب این شاخص 62% است. در عین حال، بیشتر آسیب‌پذیری‌ها را می‌توان با انتقال ساده داده‌ها به فایل‌های کانفیگ برطرف کرد.

# اسرار سخت‌نویسی شده — ناامن
password = "supersecret123"
api_key = "sk-abc123def456"

# رویکرد امن — خواندن از متغیرهای محیطی
import os
password = os.getenv("DB_PASSWORD")
api_key = os.getenv("API_KEY")

نشت از طریق سیستم کنترل نسخه

Git کل تاریخچه commitها را حفظ می‌کند. اگر رمز عبور سخت‌نویسی شده وارد مخزن شده باشد، حتی پس از حذف از نسخه فعلی در تاریخچه باقی می‌ماند. ابزارهایی مانند git-secrets و truffleHog به کشف چنین نشت‌هایی کمک می‌کنند، اما بهتر است در مرحله بازبینی کد از آنها جلوگیری کرد.

الزامات نظارتی

استانداردهای PCI DSS، GDPR و HIPAA مستقیماً ذخیره داده‌های محرمانه در کد منبع را ممنوع می‌کنند. استفاده از هاردم‌کد می‌تواند منجر به عواقب قانونی و جریمه‌ها، به ویژه در بخش‌های مالی و پزشکی شود.

چگونه در پروژه‌ها از هاردم‌کد اجتناب کنیم

گام اول برای حذف هاردم‌کد — آگاهی از مشکل در سطح تیم. بازبینی کد باید شامل بررسی مقادیر سخت‌نویسی شده باشد. لینتر یا تحلیلگر ایستایی را پیکربندی کنید که هاردم‌کد بالقوه را برجسته کند. برای TypeScript، ESLint با قانون no-hardcoded-credentials مناسب است، برای Python — Bandit.

گام دوم — پیاده‌سازی الگوی Configuration as Code. تمام پارامترهایی که ممکن است در محیط‌های مختلف متفاوت باشند، باید در متغیرهای محیطی یا فایل‌های کانفیگ ذخیره شوند. کتابخانه‌هایی مانند dotenv (Node.js)، python-decouple (Python) یا Spring Cloud Config (Java) این رویکرد را استاندارد می‌کنند.

گام سوم — استفاده از سرویس‌های مدیریت کانفیگ: Consul، etcd، Zookeeper. برای پروژه‌های ابری، AWS Parameter Store، Google Cloud Secret Manager یا Azure App Configuration مناسب هستند. در معماری میکروسرویس، مدیریت متمرکز کانفیگ حیاتی است.

• متغیرهای محیطی — برای اسرار و داده‌های حساس
• فایل‌های .env — برای توسعه محلی
• کلاس‌های کانفیگ — با خواندن از منابع خارجی
• Feature Toggles — برای فعال/غیرفعال کردن قابلیت‌ها
• بین‌المللی‌سازی — برای منابع متنی

بهترین روش‌ها

هر پارامتر کانفیگ را مستند کنید: هدف آن، مقادیر مجاز، مقدار پیش‌فرض. از اعتبارسنجی schema برای کانفیگ استفاده کنید — این امکان می‌دهد خطاها را هنگام راه‌اندازی برنامه بگیرید. یک فایل .env.example با تمام متغیرهای لازم ایجاد کنید، اما بدون مقادیر واقعی.

نمونه‌های رفکتورینگ هاردم‌کد

یک مثال مشخص در JavaScript را در نظر بگیریم. قبل از رفکتورینگ، کد شامل URL و زمان انتظار سخت‌نویسی شده است. پس از رفکتورینگ، تمام پارامترها به کانفیگ منتقل شده‌اند. این کار کد را قابل تست، انعطاف‌پذیر و امن می‌کند.

// قبل از رفکتورینگ — مقادیر سخت‌نویسی شده
const response = await fetch("https://api.example.com/v1/users", {
  timeout: 5000,
  headers: { "Authorization": "Bearer sk-abc" }
});

// پس از رفکتورینگ — مبتنی بر کانفیگ
const config = {
  apiUrl: process.env.API_URL,
  timeout: parseInt(process.env.API_TIMEOUT || "30000"),
  authToken: process.env.AUTH_TOKEN
};

const response = await fetch(config.apiUrl, {
  timeout: config.timeout,
  headers: { "Authorization": "Bearer " + config.authToken }
});

رفکتورینگ در Java

در Java هاردم‌کد اغلب به صورت رشته‌های اتصال به پایگاه داده یافت می‌شود. استفاده از Spring Boot با application.yml این مشکل را حل می‌کند: فایل حاوی پروفایل‌هایی برای محیط‌های مختلف است و کد مقادیر را از طریق annotation @Value می‌خواند.

// سخت‌نویسی شده — مثال Java
class DatabaseConnection {
    private String url = "jdbc:mysql://localhost:3306/mydb";
    private String user = "admin";
    private String password = "pass123";
}

// کانفیگ مناسب از طریق Spring Boot
@Value("${db.url}")
private String url;

هاردم‌کد در زبان‌های برنامه‌نویسی مختلف

رویکردهای مبارزه با هاردم‌کد به زبان و اکوسیستم بستگی دارد. در زبان‌های تفسیری (Python، JavaScript، Ruby) کانفیگ معمولاً در متغیرهای محیطی یا فایل‌های .env ذخیره می‌شود. در زبان‌های کامپایلری (Java، C#، Go) — در فایل‌های کانفیگ YAML، JSON، XML یا منابع داخلی.

در Python کتابخانه python-decouple محبوب است که کانفیگ را از فایل .env می‌خواند و getterهای تایپ‌شده ارائه می‌دهد. در Go از Viper استفاده می‌شود — کتابخانه قدرتمند برای کار با کانفیگ‌ها از منابع مختلف. در Swift برای توسعه iOS، کانفیگ‌ها به Info.plist یا فایل‌های Configuration جداگانه منتقل می‌شوند.

ابزارهای تحلیل ایستا مانند SonarQube، ESLint، Pylint می‌توانند به طور خودکار مقادیر سخت‌نویسی شده را تشخیص دهند. SonarQube قوانین آماده برای جستجوی اعداد و رشته‌های جادویی در کد به زبان‌های مختلف دارد. تنظیم چنین بررسی‌هایی در pipeline CI/CD — بهترین راه برای جلوگیری از ظهور هاردم‌کد جدید است.

اتوماسیون بررسی هاردم‌کد

هوک‌های Git pre-commit می‌توانند اسکریپت‌هایی را اجرا کنند که commit را از نظر وجود اسرار سخت‌نویسی شده بررسی می‌کنند. ابزار git-secrets commitها را برای تطابق با عبارت‌های منظم رمزهای عبور، کلیدها و توکن‌ها اسکن می‌کند. TruffleHog و Gitleaks فراتر می‌روند — آنها تاریخچه git را برای نشت‌ها بررسی می‌کنند.