Hackers and vulnerabilities: Injection attacks, changes in security settings, exposure of sensitive data, breach in authentication protocol

Attackers exploit vulnerabilities, weaknesses in a system, and common ones include injection attacks that slip malicious input into queries, insecure security settings, sensitive data left exposed, and broken authentication that lets attackers bypass login.

11 min read · 7 cards · 2 checks

Read in: English · हिन्दी · ગુજરાતી


Theory

The weaknesses attackers exploit

Attackers do not break in by magic; they exploit vulnerabilities, weaknesses in a system. Knowing the common vulnerabilities is how defenders close them before attackers find them.

This lesson covers frequent ones: injection attacks, insecure security settings, exposure of sensitive data, and broken authentication. You have met some already (SQL injection in databases and PHP; authentication in full-stack development); here they are framed as security vulnerabilities. Each is a hole an attacker looks for, and each has a defence that closes it.

At a glance

VulnerabilityThe weaknessDefence
Injection attacksMalicious input executed as a command (e.g. SQL injection)Validate input; use parameterised queries
Insecure security settingsMisconfiguration, weak defaults, disabled protectionsSecure configuration; review settings
Exposure of sensitive dataData unencrypted or poorly protected, so it leaksEncrypt data; restrict access
Broken authenticationWeak login lets attackers bypass or hijack itStrong authentication; secure sessions

Theory

Injection and insecure settings

An injection attack slips malicious input into a system that wrongly treats it as a command. The classic is SQL injection: typing crafted text into a form so the database runs the attacker's SQL. You learned the defence, parameterised queries and input validation, in databases and PHP; here it is named as a vulnerability class.

Insecure security settings (misconfiguration) is a quieter danger: weak default passwords left unchanged, unnecessary services enabled, protections switched off, or permissions too loose. Attackers scan for such misconfigurations because they are common and easy to exploit. The defence is careful, secure configuration and regular review, not leaving the doors unlocked.

Theory

Data exposure and broken authentication

Exposure of sensitive data happens when data is not properly protected, stored or sent without encryption, or accessible to those who should not see it, so it leaks (in a breach, or to anyone who looks). The defence is to encrypt sensitive data (in transit with SSL, and at rest) and restrict access to it.

Broken (or breached) authentication means the login mechanism is weak enough for attackers to bypass or hijack it, through weak passwords, poor session handling, or flawed login logic, letting them impersonate users. The defence is strong authentication (good passwords, two-factor) and secure session management. Together, these four vulnerabilities, injection, misconfiguration, data exposure, and broken authentication, are among the most exploited, which is why closing them is a security priority.

Quiz

An attacker types crafted input into a login form so that the database executes their own SQL command. What vulnerability is this, and how is it prevented?

  1. Broken authentication; prevented by faster servers
  2. An injection attack (SQL injection); prevented by validating input and using parameterised queries
  3. Data exposure; prevented by a DDoS filter
  4. Insecure settings; prevented by encryption alone
Show the answer

An injection attack (SQL injection); prevented by validating input and using parameterised queries

Slipping malicious input that the database wrongly runs as a command is an injection attack, specifically SQL injection, and it is prevented by validating input and, crucially, using parameterised queries (which keep user input as data, never as executable SQL). Option A misnames it: broken authentication is about weak login mechanisms, and server speed is irrelevant to injection. Option C misnames it as data exposure (which is about leaking unprotected data) and offers an unrelated defence (a DDoS filter). Option D misnames it as insecure settings and gives an incomplete defence; while good configuration helps generally, the specific fix for injection is input validation and parameterised queries. Recognise SQL injection and defend with parameterised queries, exactly as you learned in databases.

Think first

Why do these same vulnerabilities keep appearing across so many systems?

Injection and broken authentication have been known for years. Why are they still so common? Then tap.

Show the answer

Because they arise from recurring MISTAKES in how software is built and configured, not from exotic flaws, and as long as developers and administrators keep making those mistakes (often under pressure, or without security training), the same weaknesses reappear in system after system. Consider injection: it happens whenever code builds a command (like a database query) by mixing in user input without properly separating data from instructions. That is an easy, tempting shortcut, gluing strings together works and looks fine in testing, so developers do it, especially if they were never taught why it is dangerous or are rushing to ship. The correct habit (parameterised queries, input validation) is well known but must be applied EVERY time, and one forgotten spot is enough. Broken authentication similarly stems from common shortcuts: weak password rules, reused code with flaws, poor session handling, skipping two-factor, each an omission rather than an obscure bug. Insecure settings are perhaps the most human: default passwords left unchanged, protections disabled 'temporarily', permissions set too loosely to save time, so misconfiguration is rampant simply because secure setup takes care and knowledge. Data exposure follows from not encrypting or restricting access, again an omission. The pattern is that these vulnerabilities are the RESULT of predictable human and process failures, gaps in knowledge, time pressure, oversight, so they recur wherever those conditions exist, which is almost everywhere. That is also why they dominate 'most common vulnerability' lists year after year, and why security education (like this lesson) matters: knowing the classic weaknesses and their defences is how developers stop repeating them. The flaws persist because the mistakes that cause them are easy to make and easy to overlook, which is exactly why awareness and disciplined secure practices are the real fix. Known weaknesses endure because known-good practices are not consistently applied.

Summary

Key takeaways

  • A vulnerability is a weakness in a system that an attacker can exploit; knowing the common ones lets defenders close them.
  • Injection attacks slip malicious input that the system runs as a command (e.g. SQL injection); prevented by input validation and parameterised queries.
  • Insecure security settings (misconfiguration, weak defaults, disabled protections) are common and easily exploited; prevented by secure configuration and review.
  • Exposure of sensitive data occurs when data is unencrypted or poorly protected, so it leaks; prevented by encryption and restricted access.
  • Broken authentication lets attackers bypass or hijack login; prevented by strong authentication and secure session management.
  • These vulnerabilities recur across systems because they stem from common, avoidable mistakes.
  • Memory hook: injection, misconfiguration, data exposure, broken authentication, close each with its matching defence.

Study this properly

This page is the lesson to read. In Gri-Learn the same topic is a graded deck: the self-checks are scored and your weak topics are tracked. Free to start.

Start this topic

Already have an account? Sign in

More from Cyber Security Fundamentals

Gri-Learn · syllabus-mapped B.C.A. lessons in English, Hindi and Gujarati