Access with a purpose
Use the permissions needed for the job. Keep credentials out of public source and browser code. Remove access when the work no longer requires it.
Security
How I approach access, data and release decisions. The controls for a client project are agreed around its actual requirements.
Before choosing a model or a hosting service, we establish what information the product needs, who should have access and where it can be processed.
That informs the architecture, permissions and testing. It also makes the limits clear before the product is in use.
Use the permissions needed for the job. Keep credentials out of public source and browser code. Remove access when the work no longer requires it.
Collect what the feature needs. Agree retention and provider requirements. Use representative test data where live information is unnecessary.
Check changed behaviour, dependencies and the production build. Keep a version history so a release can be traced and an earlier version restored.
Define what an agent may read and do. Put review steps around consequential actions and test its behaviour against realistic examples.
Khadaffi.com is delivered through AWS Amplify over HTTPS. Public pages use self-hosted fonts and icons. There are no advertising trackers in the site code.
The enquiry form uses EmailJS. The client payment page links to Stripe’s hosted checkout. Stripe loads when you follow a payment link. The model catalogue is refreshed during publishing, so browsing it does not send your visit to a model provider.
Read the privacy policyEmail the affected URL, what you observed and enough detail to help reproduce the issue. Please avoid including personal data or secret keys.
security@khadaffi.comKeep reports private while the issue is investigated. Acknowledge the limits of your access and avoid interrupting anyone’s service.