Introduction

Common security mistakes are repeated coding, design, configuration, and testing errors that can make software unsafe.

Many security problems do not happen because developers intentionally write unsafe code. They often happen because developers forget to validate input, expose sensitive data, trust the frontend too much, use weak password handling, skip authorization checks, or ignore secure configuration.

In this lesson, students will learn the most common beginner-friendly security mistakes and the safer habits that professional developers should follow.

Easy Real-Life Example

House Mistakes:
- Leaving doors unlocked
- Keeping keys in visible places
- Not checking visitors
- Showing private information publicly

Software Mistakes:
- Not validating input
- Hardcoding passwords
- Missing authorization checks
- Showing internal errors to users

Secure programming means checking these weak points before attackers or users accidentally misuse them.

What are Common Security Mistakes?

Common security mistakes are repeated unsafe practices that make applications easier to attack, misuse, or break.

These mistakes can appear in input handling, output display, authentication, authorization, password storage, logging, file uploads, dependencies, configuration, APIs, databases, and code repositories.

Why Students Should Learn These Mistakes

Beginners often learn how to make code work, but professional software also needs to be safe, reliable, and maintainable.

Mistake 1: Trusting User Input

One of the biggest security mistakes is trusting input directly.

User input can come from forms, URLs, cookies, headers, files, APIs, or external systems. A secure program should treat all external input as untrusted until it is validated.

Bad Practice

INPUT marks

IF marks >= 40 THEN
    DISPLAY "Pass"
ELSE
    DISPLAY "Fail"
END IF

This code does not check whether marks is a number or whether it is within a valid range.

Better Practice

INPUT marks

IF marks is not a number THEN
    DISPLAY "Invalid marks"
    STOP
END IF

IF marks < 0 OR marks > 100 THEN
    DISPLAY "Marks must be between 0 and 100"
    STOP
END IF

IF marks >= 40 THEN
    DISPLAY "Pass"
ELSE
    DISPLAY "Fail"
END IF

Mistake 2: Validating Only on the Client Side

Client-side validation is useful for user experience, but it is not enough for security.

A user can bypass browser validation and send requests directly to the backend.

Mistake 3: Missing Output Encoding

Another common mistake is displaying user input directly on a page without encoding it.

If special characters are not encoded, the browser may interpret user input as markup or script instead of plain text.

Bad Practice

INPUT comment

DISPLAY comment inside web page

Better Practice

INPUT comment

safeComment = HTML_ENCODE(comment)

DISPLAY safeComment inside web page

Mistake 4: Storing Passwords as Plain Text

Passwords should never be stored in readable form.

If a database is exposed and passwords are stored as plain text, user accounts become highly vulnerable.

Bad Practice

SAVE email
SAVE password

Better Practice

passwordHash = SECURE_PASSWORD_HASH(password)

SAVE email
SAVE passwordHash

Secure applications store password hashes, not original passwords.

Mistake 5: Hardcoding Secrets in Source Code

Hardcoding secrets means placing passwords, API keys, tokens, database credentials, or private keys directly inside source code.

This is unsafe because source code may be shared, copied, logged, committed, reviewed, or leaked.

Bad Practice

databasePassword = "AdminPassword123"
apiKey = "my-secret-api-key"

Better Practice

databasePassword = GET_SECRET("DATABASE_PASSWORD")
apiKey = GET_SECRET("PAYMENT_API_KEY")

Mistake 6: Weak Authentication

Authentication verifies user identity. Weak authentication can allow unauthorized users to access accounts.

Unsafe Error Message

"User exists, but password is wrong."

Safer Error Message

"Invalid username or password."

Mistake 7: Missing Authorization Checks

Authentication proves identity, but authorization checks permission.

A common mistake is assuming that a logged-in user can access everything.

Bad Practice

FUNCTION deleteStudent(studentId)
    DELETE student record
    RETURN "Student deleted"
END FUNCTION

Better Practice

FUNCTION deleteStudent(currentUser, studentId)
    IF currentUser.role is not "Admin" THEN
        RETURN "Access denied"
    END IF

    DELETE student record
    RETURN "Student deleted"
END FUNCTION

Mistake 8: Giving Too Much Access

Giving users or services more permissions than required increases risk.

This violates the principle of least privilege.

Mistake 9: Showing Detailed System Errors to Users

Detailed technical error messages can reveal internal paths, database names, stack traces, server details, or logic clues.

Bad Practice

Database error at /internal/server/config/db_connection_line_42

Better Practice

Something went wrong while processing your request.
Please try again later.

Detailed errors should be logged securely for developers, while users should receive safe and friendly messages.

Mistake 10: Logging Sensitive Data

Logs are useful for debugging and monitoring, but logs should not contain sensitive data.

Mistake 11: Using Outdated Dependencies

Many applications depend on libraries, packages, frameworks, plugins, and third-party components.

Using outdated components with known vulnerabilities can make an application unsafe.

Safer dependency habits:
- Use trusted packages.
- Keep dependencies updated.
- Remove unused libraries.
- Review dependency vulnerabilities.
- Use dependency scanning tools when available.

Mistake 12: Unsafe File Uploads

File upload features are risky if the application accepts any file without validation.

Mistake 13: Security Misconfiguration

Security misconfiguration happens when systems, servers, frameworks, databases, APIs, cloud services, or applications are configured unsafely.

Mistake 14: Weak Cryptographic Practices

Cryptography is difficult to implement correctly. Beginners should avoid creating custom encryption or password hashing methods.

Bad Practice

Create a custom password scrambling method.

Better Practice

Use trusted security libraries and approved algorithms.

Developers should rely on tested libraries and organization-approved security standards for cryptographic operations.

Mistake 15: Skipping Code Review and Security Testing

Security issues are easier to catch when developers review code, write tests, and use security scanning tools.

Mistake 16: Blindly Trusting AI-Generated Code

AI tools can help generate code quickly, but generated code must still be reviewed and tested.

A developer is responsible for checking whether generated code is correct, secure, maintainable, and aligned with project standards.

Common Security Mistakes Summary Table

Real-World Example: E-Commerce Security Mistakes

Consider an e-commerce checkout system.

Student-Friendly Example: School Portal Security Mistakes

Common mistakes in a school portal:

1. Student marks are accepted without checking 0 to 100.
2. Student can view another student's report by changing studentId.
3. Teacher password is stored directly in database.
4. Admin password is written inside source code.
5. Error page shows database connection details.
6. Uploaded student documents are accepted without file checks.
7. Logs contain passwords during debugging.

Safer Version

Safer school portal habits:

1. Validate marks before saving.
2. Check ownership and role before showing reports.
3. Store password hashes, not passwords.
4. Keep secrets outside source code.
5. Show safe error messages to users.
6. Validate uploaded file type and size.
7. Never log passwords or secret values.

Security Mistake Prevention Checklist

Best Practices to Avoid Common Security Mistakes

Prerequisites Before Learning Common Security Mistakes

Students should understand the following topics before learning this concept deeply:

Trace Table Example: Secure Access Check

FUNCTION updateMarks(currentUser, marks)
    IF currentUser is not authenticated THEN
        RETURN "Please login"
    END IF

    IF currentUser.role is not "Teacher" AND currentUser.role is not "Admin" THEN
        RETURN "Access denied"
    END IF

    IF marks is not a number OR marks < 0 OR marks > 100 THEN
        RETURN "Invalid marks"
    END IF

    SAVE marks

    RETURN "Marks updated"
END FUNCTION

Practice Activity: Identify Security Mistakes

Review the following pseudocode and identify security mistakes.

databasePassword = "Admin123"

FUNCTION login(email, password)
    LOG "Login password is " + password

    IF email == "admin@example.com" AND password == "admin123" THEN
        RETURN "Login successful"
    ELSE
        RETURN "Wrong password"
    END IF
END FUNCTION

FUNCTION deleteUser(userId)
    DELETE user by userId
    RETURN "Deleted"
END FUNCTION

Expected Issues

Security mistakes:
1. Database password is hardcoded.
2. Password is logged.
3. Admin credentials are hardcoded.
4. Login error message is unsafe.
5. Password handling is weak.
6. deleteUser has no authorization check.
7. No input validation is shown.

Improved Concept

databasePassword = GET_SECRET("DATABASE_PASSWORD")

FUNCTION login(email, password)
    IF email is empty OR password is empty THEN
        RETURN "Invalid username or password"
    END IF

    userAccount = FIND account by email

    IF userAccount does not exist THEN
        RETURN "Invalid username or password"
    END IF

    IF VERIFY_PASSWORD(password, userAccount.passwordHash) is false THEN
        RETURN "Invalid username or password"
    END IF

    CREATE secure session

    RETURN "Login successful"
END FUNCTION

FUNCTION deleteUser(currentUser, userId)
    IF currentUser.role is not "Admin" THEN
        RETURN "Access denied"
    END IF

    DELETE user by userId

    RETURN "Deleted"
END FUNCTION

Practice Test Cases

Mini Quiz

Interview Questions on Common Security Mistakes

Quick Summary