Security Standard#

If sensitive information is in your code, anyone who can see the code can access your accounts, your data, and your users' data. This is the most common security mistake in AI-assisted development — and the easiest to prevent.

1. Open your project in whatever tool you used to build it
2. Use the search function (Ctrl+F on Windows, Cmd+F on Mac)
3. Search for each of these, one at a time: sk-, api_key, secret, password, token, DATABASE_URL
4. Also search for any long random string that looks like a key or password
5. If you find any of these in your code, move them to environment variables (your tool's settings or secrets panel)
6. Not sure how to move them? See When to Escalate

Without HTTPS, anyone on the same network (a coffee shop, a school) can read the data your tool sends and receives. This includes passwords, personal information, and anything else your users type.

1. Open your tool in a browser 2. Look at the address bar — it should start with https:// and show a lock icon 3. If it starts with http:// (no "s"), your data is not encrypted 4. Most modern hosting tools (Replit, Vercel, Netlify) provide HTTPS automatically. If yours does not, contact your reviewer.

Data you do not have cannot be stolen. The safest way to protect information is to never collect it in the first place.

AI tools sometimes send data to third-party services for processing. If you did not choose and approve that service, you do not know what happens to your data.

1. List every external service your tool connects to (AI APIs, databases, analytics, etc.) 2. Check each one against Springpod's Approved Tools list 3. If any service is not on the approved list, stop and get approval before shipping

Unvalidated input is the most common way attackers exploit tools. It can also cause your tool to crash or show wrong data.

1. Find every form, text field, or input in your tool 2. Try typing something unexpected in each one (text in a number field, symbols in a name field, an extremely long string) 3. The tool should show a clear message explaining what is expected — not crash or accept bad data silently

Technical error messages tell attackers exactly how your tool is built, what database you use, and where to find vulnerabilities. They are a roadmap for exploitation.

If someone gains access to your database or intercepts network traffic, encrypted data is unreadable without the key. Unencrypted data is immediately exposed.

1. In transit: Confirmed if you use HTTPS (checked above) 2. At rest: Check your database provider's documentation — most modern services (Supabase, Firebase, AWS RDS) encrypt by default. Confirm this is enabled. 3. If you are not sure, flag it in your Review Request for your technical reviewer to verify

This is one of the most common security failures in web applications. It is easy to miss because the tool "works" — it just shows the wrong person's data.

1. Create two test accounts 2. Log in as Account A and note the URL when viewing personal data 3. Log in as Account B and paste Account A's URL — you should NOT see Account A's data 4. If you can see another account's data, stop and fix this before shipping

Keeping data forever increases your risk. Many regulations require you to delete data when you no longer need it.

You cannot protect data you do not know is leaving your system. This list is required for security reviews and compliance audits.

For tools handling protected data (especially data about minors), a Data Protection Impact Assessment (DPIA) may be a legal requirement, not just a best practice.

Children and young people have special legal protections. In the UK, the age of consent for data processing in online services is 13 (UK GDPR). In the EU, GDPR Article 8 allows member states to set the threshold between 13 and 16. Springpod policy may set stricter limits.

1. List every piece of data your tool collects about users under 18 2. For each item: is it strictly necessary for the tool to function? If not, remove it 3. Check if your tool uses any analytics or tracking — disable for minors 4. Check Springpod's policy on parental notification 5. If unsure about any of these, escalate to your designated reviewer

Privacy compliance is a specialist skill. Even well-meaning builders can miss requirements. This is why Red builds require sign-off from a designated reviewer.

When something goes wrong, you do not have time to figure out what to do. Having a plan means you respond in minutes, not hours.

1. Open your incident response plan (or create one using the Incident Report template) 2. Can you answer: who is called first? How do you turn the tool off? Where are the access credentials? 3. If any of these are blank, fill them in now

You are responsible for your users' data even after you send it to someone else. A data processing agreement makes the third party legally accountable too.

Without a login, anyone with the URL can access your users' data.

The NCSC (the UK's National Cyber Security Centre) recommends three random words as the best balance of strength and memorability. Do not force regular password changes — only require a change when compromise is known or suspected. Lock accounts after 10 failed attempts. Encourage password managers and enable multi-factor authentication wherever possible.

An unlocked session on an unattended computer is an open door to someone's data.

Admin accounts are the highest-value target. If an attacker gets one admin password, MFA prevents them from accessing the system.

If something goes wrong, the audit log tells you what happened, when, and who was involved. Without it, you are investigating blind.