5 Cybersecurity Mistakes Indian Startups Make (And How to Fix Them)

What We Found Scanning Indian Startups

After scanning hundreds of Indian startup domains, we've identified patterns that repeat with alarming consistency. These aren't exotic zero-days — they're basic misconfigurations that automated bots exploit in minutes.

Let's break down each mistake, show you exactly how attackers exploit it, and give you copy-paste fixes.

Mistake #1: Exposed Admin Panels

This is the single most common vulnerability we find. Startups leave /admin, /wp-admin, /phpmyadmin, and staging subdomains accessible to the entire internet.

sequenceDiagram
    participant Bot as 🤖 Attacker Bot
    participant Site as 🌐 Your Website
    participant Admin as 🔐 Admin Panel
    Bot->>Site: GET /admin (200 OK)
    Bot->>Admin: Brute-force login
    Admin-->>Bot: Access granted (weak password)
    Bot->>Admin: Create backdoor user
    Bot->>Site: Deface / exfiltrate data

How to fix it

Option A: Restrict by IP (Nginx)

location /admin {
    allow 203.0.113.50;   # Your office IP
    allow 10.0.0.0/8;     # Your VPN range
    deny all;
    return 403;
}

Option B: Restrict by IP (AWS Security Group)

# Allow admin access only from your office IP
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxx \
  --protocol tcp --port 443 \
  --cidr 203.0.113.50/32 \
  --description "Admin access - office IP"

Option C: Add 2FA to every admin login — use TOTP (Google Authenticator) or hardware keys.

Mistake #2: Outdated Software with Known CVEs

We regularly see WordPress installations running plugins last updated two years ago, Node.js apps using dependencies with published CVEs, and servers running end-of-life operating systems.

Real examples from recent scans

How to fix it

# For Node.js projects — audit and auto-fix
npm audit
npm audit fix

# For WordPress — update everything
wp plugin update --all
wp core update

# For Ubuntu/Debian — enable automatic security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Mistake #3: Default or Weak Credentials

We still find databases accessible with admin/admin, servers with unchanged default SSH passwords, and API keys hardcoded in public GitHub repos.

graph TD
    A[🔑 Default Credentials] --> B[admin/admin]
    A --> C[root/password]
    A --> D[test/test123]
    B --> E[💀 Full Database Access]
    C --> E
    D --> E
    E --> F[📦 Data Exfiltration]
    E --> G[🔐 Ransomware Deployment]
    style A fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
    style E fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0

How to fix it

# Generate a strong password from the command line
openssl rand -base64 24
# Output: something like "Kx7mN2pQ9vLw3cRt8yHj5sFg"

# Check if your email/password has been leaked
# (Use the API, don't paste passwords into websites)
curl -s "https://api.pwnedpasswords.com/range/$(echo -n 'your-password' | sha1sum | head -c 5)"

Mistake #4: Missing or Misconfigured HTTPS

No HTTPS means all data between your users and your server travels in plain text. Anyone on the same network can read it — including passwords, personal data, and payment information.

What we commonly find

1. HTTP site with no redirect to HTTPS
2. HTTPS with expired or self-signed certificate
3. HTTPS but with TLS 1.0/1.1 still enabled (deprecated)
4. Mixed content (HTTPS page loading HTTP resources)
5. Missing HSTS header (allows downgrade attacks)

How to fix it

# Get free SSL with Let's Encrypt + auto-renewal
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

# Force HTTPS redirect (Nginx)
server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$server_name$request_uri;
}

Add these security headers to your web server config:

# Essential security headers
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';" always;

Mistake #5: Zero Logging or Monitoring

This is the silent killer. Most breaches are discovered months after they happen, often by a third party rather than the victim. If you don't have logging, you have no way to:

1. Detect an ongoing attack
2. Understand the scope of a breach
3. Meet CERT-In's 6-hour reporting requirement
4. Provide evidence to the Data Protection Board

graph LR
    A[🚨 Breach Occurs] --> B{Monitoring?}
    B -->|Yes| C[⏱️ Detected in minutes]
    B -->|No| D[📅 Discovered months later]
    C --> E[🛡️ Contained quickly
Minimal damage]
    D --> F[💀 Massive data loss
Regulatory penalty
Reputation destroyed]
    style C fill:#1e5f3a,stroke:#10B981,color:#e2e8f0
    style F fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0

Minimum viable monitoring

# 1. Enable access logging (Nginx)
access_log /var/log/nginx/access.log combined;
error_log /var/log/nginx/error.log warn;

# 2. Set up fail2ban for brute-force protection
sudo apt install fail2ban
sudo systemctl enable fail2ban

# 3. Monitor failed login attempts
sudo grep "Failed password" /var/log/auth.log | tail -20

# 4. Set up a free uptime + alert tool
# Use ntfy.sh (free, self-hostable) or UptimeRobot (free tier)

Summary: The Fix Checklist

Want to Know What You're Missing?

Our free VAPT scan checks for all five of these common issues — and dozens more. You get a prioritized list of what to fix first based on actual risk severity.

Written by Shouvik Mukherjee, Founder & CEO of Bachao.AI. Follow me on LinkedIn for daily cybersecurity insights for Indian businesses.