Salil Apte

Posted on Jul 18

How Attackers Think: A Developer's Guide to Seeing Security Through an Attacker's Eyes

#cybersecurity #ai #development #webdev

"Security isn't about building walls. It's about understanding how someone will try to climb over them."

Most developers build software with one person in mind: the user.

Attackers don't.

While you're thinking about user journeys, feature releases, and improving UX, attackers are asking very different questions:

Can I bypass authentication?
Can I access another user's data?
Can I manipulate API requests?
Can I make the application trust me?
What assumptions did the developers make?

One of the biggest mindset shifts a developer can make is learning to think like an attacker—not to exploit systems, but to build software that's resilient against misuse.

Let's walk through how attackers typically approach an application and, more importantly, what developers can learn from that mindset.

The Attacker's Objective

Contrary to popular belief, most attackers aren't trying to write sophisticated malware or discover movie-worthy zero-day exploits.

Most attacks have straightforward goals:

Steal data
Obtain credentials
Gain unauthorized access
Execute arbitrary code
Encrypt systems for ransom
Abuse cloud resources
Monetize compromised systems

Every action they take serves one of these objectives.

Before writing a single exploit, they spend time understanding the target.

Phase 1: Reconnaissance

Professional attackers spend far more time gathering information than exploiting vulnerabilities.

They want to answer questions such as:

Which technologies power the application?
Is it running on AWS, Azure, or Google Cloud?
Which framework versions are being used?
Which APIs are publicly accessible?
Are there staging environments exposed?
Does GitHub contain leaked credentials?
Are there forgotten subdomains?
Which employees have privileged access?

This process is known as reconnaissance.

Some common public sources include:

GitHub repositories
DNS records
Certificate Transparency logs
Search engines
Public documentation
Job postings
Technical blog posts
Public cloud storage

Attackers love information that developers accidentally expose.

A forgotten backup file or a public .env file can be worth more than an expensive exploit.

Phase 2: Mapping the Attack Surface

Once they understand the target, attackers begin identifying everything they can interact with.

Developers often think about features:

Login
Dashboard
Payments
Profile
Admin Panel

Attackers think about entry points:

Login endpoint
Password reset
Registration
API endpoints
File uploads
Webhook handlers
Admin APIs
GraphQL endpoints
Mobile APIs
Third-party integrations

Every exposed endpoint becomes a potential opportunity.

The larger the attack surface, the more opportunities exist for mistakes.

Phase 3: Testing Every Input

Attackers don't trust your validation.

Instead, they ask:

What happens if I send negative numbers?
What if I submit a 100 MB payload?
Can I upload executable files?
What if I remove required parameters?
Can I inject unexpected characters?
Does the server validate anything?

For example, while a normal user submits:

{
  "email": "alice@example.com"
}

An attacker might try:

{
  "email": "' OR 1=1 --"
}

Or:

{
  "role": "admin"
}

Or even:

{
  "price": -5000
}

Attackers aren't using the application as intended.

They're trying to discover assumptions the developers made.

Phase 4: Breaking Authentication

Authentication is usually one of the first major targets.

Attackers look for weaknesses such as:

Weak passwords
Password reuse
Credential stuffing
Brute-force attacks
Predictable reset tokens
Session fixation
Weak JWT validation
Missing Multi-Factor Authentication (MFA)

Their goal isn't always to hack passwords.

Sometimes it's much easier to steal a valid session cookie.

If authentication fails, everything behind it becomes vulnerable.

Phase 5: Exploiting Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

Many applications get the first part right and the second part wrong.

Consider this API:

GET /api/users/123/profile

An attacker changes it to:

GET /api/users/124/profile

If the server returns another user's profile, you've just exposed sensitive data.

This type of vulnerability is known as Broken Object Level Authorization (BOLA) or Insecure Direct Object Reference (IDOR).

It's one of the most common API security issues.

The fix isn't hiding IDs.

The fix is verifying ownership on every request.

Phase 6: Looking Beyond the UI

Developers spend months polishing user interfaces.

Attackers usually ignore them.

Instead, they inspect network traffic.

They call APIs directly.

They modify requests.

They automate thousands of requests using scripts.

Modern applications expose functionality through APIs, making the backend the real attack surface.

This is why server-side validation is essential.

Anything enforced only in the frontend can be bypassed.

Phase 7: Chaining Small Weaknesses

Rarely does a single vulnerability lead to a catastrophic breach.

Instead, attackers combine multiple small issues.

Imagine this sequence:

Weak password

↓

Credential stuffing

↓

Account compromise

↓

Privilege escalation

↓

Cloud credential access

↓

Production database access

↓

Data exfiltration

Each individual issue might seem minor.

Together, they become devastating.

Security professionals often refer to this as an attack chain.

Breaking any link in the chain can stop the attack.

Phase 8: Targeting Misconfigurations

Hollywood loves zero-day exploits.

Reality is far less glamorous.

Many successful attacks happen because of simple configuration mistakes.

Examples include:

Public cloud storage buckets
Default administrator credentials
Debug mode enabled in production
Open databases
Overly permissive IAM roles
Secrets committed to Git
Unpatched dependencies
Exposed management consoles

These mistakes are far more common than sophisticated vulnerabilities.

Phase 9: Attacking the Cloud

Applications no longer live on a single server.

Today's infrastructure includes:

Kubernetes
Docker
AWS
Azure
Google Cloud
CI/CD pipelines
Serverless functions

Attackers increasingly focus on cloud identities instead of operating systems.

Typical targets include:

IAM roles
Temporary credentials
Metadata services
Kubernetes secrets
Service accounts
API keys

Identity has become the new security perimeter.

Phase 10: Compromising the Software Supply Chain

Your application is only one piece of your environment.

Attackers increasingly target:

Open-source packages
CI/CD pipelines
Build servers
Package repositories
Third-party libraries

A compromised dependency can affect thousands of downstream applications.

Developers should:

Regularly update dependencies
Verify package sources
Enable dependency scanning
Review build pipelines
Use Software Bill of Materials (SBOMs)

Supply chain security is now a core part of software engineering.

Phase 11: Exploiting Human Behavior

The most sophisticated firewall can't stop someone from voluntarily giving away their credentials.

Attackers frequently use:

Phishing emails
Fake login pages
Social engineering
Fake recruiters
SMS scams
Voice phishing
MFA fatigue attacks

Humans remain one of the most targeted attack vectors.

Security awareness matters just as much as secure code.

Phase 12: Maintaining Persistence

After gaining access, attackers often try to stay inside the environment.

Common persistence techniques include:

Creating hidden accounts
Installing SSH keys
Creating scheduled tasks
Registering new API tokens
Deploying backdoors
Creating OAuth applications

The longer they remain undetected, the more damage they can cause.

Phase 13: Covering Their Tracks

Professional attackers don't want defenders to know they were there.

Typical actions include:

Deleting logs
Clearing shell history
Modifying timestamps
Disabling monitoring
Blending into legitimate traffic
Removing forensic evidence

Good logging and centralized monitoring make these activities significantly harder.

How Developers Should Think

Instead of asking:

"Does this feature work?"

Ask:

What assumptions am I making?
What happens if every input is malicious?
Can users access data they shouldn't?
What if a session token leaks?
What if an attacker controls the client?
What happens if one service is compromised?
What's the blast radius?

Security is largely about questioning assumptions.

Practical Security Checklist

Before deploying an application, ask yourself:

Authentication

Is MFA enabled for privileged users?
Are passwords securely hashed?
Are login attempts rate-limited?
Are sessions invalidated on logout?

Authorization

Is every request authorized server-side?
Are object ownership checks implemented?
Are admin endpoints protected?

Input Validation

Are all inputs validated?
Are uploaded files scanned?
Are size limits enforced?
Are dangerous file types blocked?

Secrets

Are secrets stored outside source code?
Are API keys rotated regularly?
Are credentials encrypted?

Infrastructure

Are unnecessary ports closed?
Are dependencies updated?
Is debug mode disabled?
Are cloud permissions based on least privilege?

Monitoring

Are security events logged?
Are logs centralized?
Are alerts configured for suspicious behavior?
Is incident response documented?

The Biggest Lesson

The best security engineers don't think like developers.

They think like curious, persistent adversaries.

They assume:

Every input can be manipulated.
Every endpoint will be tested.
Every assumption will be challenged.
Every shortcut will eventually be discovered.

If you build software with those assumptions in mind, you'll naturally create systems that are far more resilient.

Final Thoughts

Security isn't about being paranoid.

It's about being prepared.

Attackers don't follow the happy path. They explore edge cases, unexpected inputs, forgotten configurations, and misplaced trust. By adopting that perspective during design, development, and testing, developers can identify weaknesses long before they become incidents.

You don't need to become an ethical hacker overnight. Start by asking one simple question every time you build a feature:

"If I wanted to break this, where would I start?"

That single question can transform the way you design software—and make your applications significantly more secure.

DEV Community