When building an application, it's easy to focus on whether the feature works.
The login works.
The API returns data.
The payment page loads.
But security problems often hide in the parts we don't think about.
I've seen developers make some of these mistakes simply because they were trying to get the application working first. Here are a few worth checking in your own projects.
1. Hardcoding API Keys
Putting something like this directly in your source code is asking for trouble:
API_KEY = "your-secret-key"
Even if you remove it later, the key may still exist in Git history.
Use environment variables or a proper secrets manager instead.
And if a secret has already been exposed, don't just delete the line. Rotate the key.
2. Trusting User Input
Never assume that data coming from a user is safe.
A username, email address, search query, uploaded file, or form field can contain unexpected input.
Validate input on the server side and use appropriate output encoding and parameterized queries.
Client-side validation is useful for user experience, but it should never be your only security control.
*3. Returning Too Much Data From an API
*
Sometimes an API returns an entire database object when the frontend only needs two fields.
For example:
{
"name": "John",
"email": "john@example.com",
"password_hash": "...",
"internal_id": 12345
}
The frontend may only need the name and email.
Return only what the client actually needs.
This reduces accidental information exposure.
*4. Forgetting Authorization Checks
*
Authentication answers:
"Who are you?"
Authorization answers:
"Are you allowed to do this?"
A user being logged in doesn't automatically mean they should be able to access every resource.
For example:
GET /api/users/102/profile
The server should verify that the current user is actually allowed to access that profile.
Don't rely on hiding buttons in the frontend.
The backend needs to enforce permissions.
*5. Weak Password Storage
*
Passwords should never be stored as plain text.
If your database is compromised, plaintext passwords immediately become a major problem.
Use a password hashing algorithm designed for password storage, such as Argon2id, bcrypt, or scrypt, with appropriate configuration.
And remember: encryption and password hashing are not the same thing.
*6. Ignoring Security Headers
*
HTTP security headers can provide another layer of protection.
Depending on your application, consider headers such as:
Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
You don't necessarily need every header blindly.
Understand what each one does and configure it according to your application's requirements.
*7. Leaving Debug Features Enabled
*
Debugging tools are useful during development.
They can also expose sensitive information.
Before deploying to production, check whether your application is accidentally exposing:
Stack traces
Environment variables
Internal paths
Database errors
Debug endpoints
Development credentials
Production should not behave like your local development environment.
*8. Never Testing the Security Side
*
You don't need to become a penetration tester to start testing your application's security.
Try asking simple questions:
What happens if this parameter is changed?
Can one user access another user's data?
What happens with invalid input?
Can an unauthenticated user access this endpoint?
What happens after logging out?
Are sensitive values appearing in browser storage or logs?
These basic checks can reveal surprisingly serious problems.
*A Simple Pre-Deployment Checklist
*
Before pushing an application to production, take a few minutes to check:
[ ] No secrets in source code
[ ] User input is validated
[ ] Database queries use parameters
[ ] Authorization is enforced server-side
[ ] Passwords are securely hashed
[ ] Sensitive data isn't exposed through APIs
[ ] Debug mode is disabled
[ ] Security headers are configured
[ ] Dependencies are updated
[ ] Error messages don't reveal internal information
Security isn't something that should be added after the application is finished.
The earlier you think about it, the easier it becomes to build it into the application naturally.
You don't have to know every security technique on day one. Start by understanding how your application handles input, authentication, authorization, data, and errors.
Those five areas alone can teach you a lot about secure development.
Top comments (0)