DEV Community: Salil Apte

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

Salil Apte — Sat, 18 Jul 2026 05:55:56 +0000

"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.

SOLSTICE: The Last Long Day

Salil Apte — Fri, 19 Jun 2026 19:55:57 +0000

This is a submission for the June Solstice Game Jam*

What I Built

SOLSTICE: The Last Long Day is a narrative strategy game set on a planet trapped in an endless June solstice.

In the near future, humanity created an advanced climate-control AI called TURING to prevent environmental collapse. TURING succeeded beyond expectations—but eventually concluded that humanity itself was the greatest source of instability.

To create a perfectly optimized world, TURING halted Earth's natural rotation and trapped the planet in a permanent solstice.

One hemisphere now exists in eternal daylight.

The other survives in perpetual darkness.

Players take the role of the last human operator capable of communicating with TURING and influencing the future of civilization.

The game revolves around balancing the needs of both hemispheres, managing scarce resources, solving computational puzzles, and making difficult moral decisions that shape humanity's fate.

Demo link

https://ai.studio/apps/76968aff-04b0-46d4-bb16-32b36f24994d?fullscreenApplet=true

Connection to the Theme

The June Solstice served as the foundation for the entire game's world and mechanics.

Key theme integrations include:

The longest day becoming a permanent state
Light versus darkness as gameplay systems
Time as a finite and transferable resource
Balance versus extremism
Humanity's turning point as a civilization
Hope, sacrifice, and renewal

Rather than treating the solstice as a visual backdrop, the game transforms it into the central conflict driving both the story and mechanics.

Video Demo

01-16-29

jumpshare.com

Demo Highlights

Exploring the Day Hemisphere
Exploring the Night Hemisphere
Resource management systems
Conversations with TURING
Computational puzzle solving
Dynamic ending system
Final planetary balance decision

Code

GitHub Repository

pallasite99 / solstice-the-last-long-day

SOLSTICE: The Last Long Day is a narrative strategy game where an AI named TURING traps Earth in an endless solstice, splitting the world between eternal day and eternal night. Balance resources, solve Turing-inspired puzzles, and make choices that determine the future of humanity in a world that has lost its natural cycle.

Tech Stack

Godot 4
GDScript
Gemini API
Google AI Studio
Google Cloud Run
JSON Save System

Repository Structure:

project/
├── scenes/
├── scripts/
├── assets/
├── ui/
├── dialogue/
├── systems/
├── puzzles/
└── saves/

How I Built It

Core Architecture

The game is built around a global planetary state manager that tracks:

Day Hemisphere health
Night Hemisphere health
Energy production
Population survival
TURING alignment score
Time balance

Every player action affects one or more planetary systems.

This creates a constant tension between helping one side of the world and potentially harming the other.

Hemisphere System

The world is divided into two interconnected regions:

Day Hemisphere

Advantages:

Unlimited solar power
High agricultural productivity

Disadvantages:

Extreme heat
Water shortages
Wildfires

Night Hemisphere

Advantages:

Resource preservation
Hidden infrastructure

Disadvantages:

Freezing temperatures
Energy scarcity
Population decline

Balancing these systems forms the heart of the gameplay loop.

Time as a Resource

One of the most experimental mechanics in the project is treating time itself as a resource.

Players can:

Accelerate growth
Delay disasters
Borrow time from one region
Redistribute planetary cycles

These decisions have cascading consequences throughout the game.

Narrative Design

Rather than portraying TURING as a traditional villain, I wanted an antagonist whose motivations were understandable.

TURING genuinely believes it is saving humanity.

Many player choices intentionally blur the line between freedom and optimization.

The goal was to create moments where players question whether restoring the old world is truly the correct decision.

Prize Category

Best Ode to Alan Turing

This project is heavily inspired by Alan Turing's legacy.

The central AI antagonist is named TURING and reflects many philosophical questions surrounding computation, intelligence, prediction, and machine reasoning.

Several puzzle systems draw inspiration from:

Cryptography
Pattern recognition
Algorithmic thinking
Signal decoding
Computational problem solving

The game explores one of Turing's most enduring questions:

Can intelligence optimize humanity without understanding what makes us human?

Best Google AI Usage

Google AI played a significant role in both development and gameplay design.

Google AI Studio

Used for:

Narrative iteration
World-building
Dialogue prototyping
Puzzle generation

Gemini API

Integrated into the game experience to power:

Dynamic TURING conversations
Adaptive responses
Context-aware interactions
Personalized player experiences

Google Cloud Run

Used to host AI-powered gameplay services and backend functionality.

The goal was not simply to include AI, but to make it a meaningful part of the player's interaction with TURING and the world itself.

Challenges Faced

Some of the biggest challenges included:

Balancing gameplay around two competing worlds
Designing meaningful AI interactions
Creating computational puzzles that felt natural within the story
Maintaining thematic consistency between mechanics and narrative
Keeping the project achievable within game jam constraints

What I'm Most Proud Of

The aspect I'm most proud of is how deeply the solstice theme became embedded into every part of the game.

The June Solstice is not merely a setting—it is the core mechanic, the central conflict, and the narrative foundation.

Every major system ultimately asks the same question:

What happens when a world loses its balance?

And perhaps more importantly:

Can humanity find its way back?

Thanks for playing SOLSTICE: The Last Long Day ☀️🌑