For a small business website or online store, most real protection comes from five habits: never handle card numbers yourself, keep everything updated, lock down admin access, keep backups you have actually restored, and design security in from the start instead of adding it before launch. The checklist below covers each one in plain words.
1. Let the payment processor hold the card
The safest card number is one your site never sees. With a hosted checkout or embedded payment fields from a processor such as Stripe, the card details go straight from the customer's browser to the processor, and your site only receives a token and the result.
Why it matters:
- A break-in on your site cannot leak card numbers it never stored.
- Your obligations under PCI DSS, the card industry's security standard, become much smaller than if card data passed through your servers.
- The processor handles extra checks such as 3-D Secure.
At AtrbCode we take our own payments this way, through Stripe. If your site already exists, our Payment Gateway add-on ($93, one-time) implements a payment gateway for it, and API Integration ($98) connects other payment providers or services.
Where card payments are not the norm, for example cash on delivery in parts of the Middle East, the same principle applies to personal data: collect only what you need to deliver the order.
2. HTTPS everywhere
Every page, not just checkout, should load over HTTPS, and plain HTTP addresses should redirect to it. Modern browsers warn visitors about forms on insecure pages, and an HTTPS certificate is free and easy to renew automatically. Treat it as the baseline, not a feature.
3. Admin access: the door attackers try first
Most small-site break-ins are not clever. They use a guessed or leaked password on an admin account.
- Give every person their own admin account; never share one login.
- Use long unique passwords and a password manager.
- Turn on two-step sign-in for every admin and for your hosting, domain and email accounts.
- Remove accounts the day someone leaves.
- Give staff the least access they need: someone who packs orders does not need to change prices.
4. Keep software updated
Outdated software is the other common way in. That includes the platform, its plugins or libraries, the server and anything your developer installed and forgot.
- Know what your site runs on and who is responsible for updating it.
- Apply security updates promptly, not "at the next redesign".
- Remove plugins and features you no longer use; unused code still has holes.
5. The well-known weak spots in custom code
If your site has custom features, its developer should be guarding against the common web vulnerabilities, the kind listed in the OWASP Top 10. Three you can ask about directly:
- Access control: can a logged-in customer see someone else's order by changing a number in the address?
- Injection: is everything a visitor types treated as data, never as a database command or page code?
- Secrets: are passwords stored as secure hashes, and are API keys kept out of the code and the browser?
A good developer can explain how each is handled in a couple of sentences.
6. Backups you have restored
A backup you have never restored is a hope, not a backup.
- Back up both the database and uploaded files, automatically.
- Keep copies somewhere other than the same server.
- Test a restore regularly, so you know how long it takes and that it works.
7. Personal data and privacy
Collect only the data you need, explain what you collect and why in a clear privacy policy, protect it, and delete it when you no longer need it. If you sell to people in the UK or the EU, the UK GDPR and EU GDPR set rules on this; other countries have their own laws, so check the ones that apply to your customers.
Why "we will add security later" fails
Security is not a layer painted on at the end. Who can see which records, how passwords and keys are stored, how payments flow: these decisions shape the data model and the code. Changing them after launch means reworking the core of the system, usually under pressure after something has gone wrong. Building them in from the first day costs a fraction of retrofitting them.
The short checklist
- Card details go to the payment processor, never through your server
- HTTPS on every page, HTTP redirects to HTTPS
- Personal admin accounts, strong passwords, two-step sign-in
- Hosting, domain and email accounts protected the same way
- Platform, plugins and server updated; unused ones removed
- Custom code checked for access control, injection and secret storage
- Automatic backups stored off the server, restore tested
- Privacy policy that matches what you actually collect
If you are unsure where your site stands, our Bug Fix & Optimization service ($30) diagnoses and fixes problems on sites we built and on sites we did not.
FAQ
Does a small shop really get attacked?
Yes, but rarely by someone targeting you personally. Automated tools scan the whole internet for weak passwords and outdated software. Small sites are hit because they are easy, not because they are interesting.
Is an HTTPS certificate enough to make my store secure?
No. It protects data on the way between the visitor and your server. It does nothing about weak admin passwords, outdated plugins or bugs in your code.
Do I need to be PCI DSS compliant if I use Stripe?
Card rules still apply to you, but using a hosted checkout or the processor's payment fields keeps card data off your systems, which makes your part much simpler. Your processor explains exactly what is expected of you.
Can you check a site someone else built?
Yes. That is a normal part of our Bug Fix & Optimization work.
For new stores and platforms with security built in from the start, see our web services.