You do not need to read code to protect a website. Most real incidents are boring: a password reused from another service, an admin account without a second step, a secret key pasted where anyone can see it, or a form that trusts whatever it receives.
This checklist is written for owners, not engineers. Nothing here makes a site unhackable, but each item removes a common way in. Share it with whoever builds or maintains your site, including Uttra when you build there by chat.
Most hacked sites fall to weak or reused passwords, outdated software and leaked keys, not to movie-style attacks. Fix those four things and you are ahead of the majority.
Accounts: your weakest link
Your hosting, domain registrar, email and GitHub accounts are worth more to an attacker than your homepage. Whoever controls them controls your site.
- Use a password manager and a unique, long password for every account.
- Turn on two-factor authentication everywhere it exists, especially email and your domain registrar.
- Never share one login between team members; give each person their own access and remove it when they leave.
- Recover access first: keep your recovery email and phone number current.
Secret keys and what never goes in the page
API keys for payments, email or AI services are like passwords for machines. If one is pasted into front-end code, anyone can open the browser tools and copy it.
Keep secrets on the server side or in the platform's secrets settings, never inside screenshots, chat messages sent to others, or public GitHub repositories. If a key has ever leaked, do not hide it: revoke it at the provider and create a new one.
Forms, logins and user data
Every form is a door. Ask your builder to check that the server validates input, limits repeated attempts and never shows raw error details to visitors.
- Collect only the data you really need; what you do not store cannot leak.
- Never store passwords in plain text; use a proven login method.
- Make sure the site runs on HTTPS only, with no mixed insecure content.
- Do not take card numbers yourself; use a payment provider's hosted checkout.
Updates and third-party code
Old libraries have known holes that attackers scan for automatically. Remove plugins, scripts and widgets you no longer use, and update the rest on a schedule, for example monthly. Load third-party scripts only from sources you trust.
In a GCC context, also be aware that government bodies such as the National Cybersecurity Authority publish baseline controls; if you serve regulated clients, ask what they require of you.
Ask for a security pass in chat
When you build with Uttra you can request a review in plain language. A prompt you can paste:
"Review my site for basic security: make sure forms validate input and limit repeated submissions, no secret keys appear in front-end code, everything is served over HTTPS, and list anything I should do manually such as turning on two-factor authentication."
Treat the answer as a checklist to confirm, not as a guarantee. Keep a backup too, because prevention never reaches 100 percent.