Security Practices

Last updated: 18 September 2026

Access control

Access should be limited to the people and services that need it, using separate accounts where supported, least privilege, protected credentials, and removal of access when a team member or vendor no longer needs it. Production credentials should never be placed in source control or public forms.

Application and deployment

Backups and recovery

Backups, restore testing, retention, and recovery objectives should be defined for each production system. The website's local demo gallery and JSON lead storage are not a substitute for a production backup or disaster-recovery plan.

Vulnerability handling

Report suspected security issues privately to mdzulhasuddin95@gmail.com with the affected URL, steps to reproduce, impact, and any safe evidence. Do not include passwords, private keys, or personal data. We will acknowledge a useful report and coordinate a fix or mitigation based on severity and environment.

Data residency and third parties

Data location depends on the hosting provider, email/webhook service, payment provider, cloud region, and other integrations selected for a project. The proposal should identify material providers and regions when residency requirements apply.

Current website notes

The Express server applies baseline security headers, validates contact data, limits contact attempts, hides lead storage from static access, and supports an optional private notification webhook. Gallery uploads are disabled by default and require the administrator to configure GALLERY_UPLOAD_TOKEN and send it in the private x-gallery-upload-token header before uploads are accepted.

Security planning

For a new system, ask for an access model, backup plan, deployment process, dependency/update policy, logging plan, incident contact, and data-residency requirements during discovery.