Top Cybersecurity Vulnerabilities in Custom Software

Off-the-shelf software ships with a known attack surface. Thousands of researchers, bug bounty hunters, and security teams scrutinise it constantly. Custom software is different — it's built specifically for your business, which means its vulnerabilities are uniquely yours too.

That's not a reason to avoid custom development. It's a reason to build it right from the start.

Here are the most common security vulnerabilities we encounter when auditing and building bespoke software — and what it takes to address each one.

1. Injection Attacks (SQL, NoSQL, Command)

Injection remains the most exploited vulnerability class in custom applications. It happens when untrusted data is sent to an interpreter as part of a command or query.

A developer writes a database query that concatenates user input directly into the SQL string. An attacker submits '; DROP TABLE users; -- as their username. The database executes it.

How to prevent it:

• Use parameterised queries and prepared statements — always
• Apply an ORM with strict input binding
• Validate and sanitise all user-supplied data at the boundary, not just in the UI
• Never trust data from any external source, including your own APIs

Modern frameworks make parameterised queries the default. If your codebase has raw string concatenation in database calls, that's a critical finding that needs immediate attention.

2. Broken Authentication and Session Management

Custom authentication is hard to get right. Many teams build their own login systems without fully understanding the attack vectors: credential stuffing, session fixation, token leakage, and brute force.

Common mistakes include:

• Storing passwords in plain text or with weak hashing (MD5, SHA-1)
• Using predictable session tokens
• Not expiring sessions after logout or inactivity
• Transmitting tokens in URL parameters (logged by proxies and servers)

How to prevent it:

• Use a battle-tested authentication library rather than rolling your own
• Hash passwords with bcrypt, Argon2, or scrypt — never MD5 or SHA-1
• Implement multi-factor authentication for sensitive operations
• Use short-lived JWTs with refresh token rotation
• Set HttpOnly, Secure, and SameSite flags on all session cookies

Authentication is one area where custom code should lean heavily on proven libraries. The attack surface is too well-understood to improvise.

3. Insecure Direct Object References (IDOR)

This is one of the most underestimated vulnerabilities in custom applications. An IDOR occurs when an application uses user-controllable input to access objects directly — without verifying that the user is authorised to access them.

A classic example: a user changes /api/invoices/1042 to /api/invoices/1043 in their browser and sees another customer's invoice. The application authenticated the user but never checked whether they owned that resource.

How to prevent it:

• Enforce authorisation checks at every data access point, not just at the route level
• Use indirect references (UUIDs, opaque tokens) instead of sequential integer IDs where possible
• Implement row-level security in your database layer
• Write automated tests that verify cross-user data access is blocked

IDOR vulnerabilities are often invisible in code review because the logic looks correct — the bug is in what's missing, not what's there.

4. Security Misconfiguration

Custom software often runs on infrastructure configured by the same team that built the application. When developers manage their own servers, containers, and cloud environments, security misconfigurations are common.

Typical findings include:

• Default credentials left on databases, admin panels, and third-party services
• Verbose error messages exposing stack traces and internal paths in production
• Unnecessary ports and services left open
• Overly permissive CORS policies
• Debug endpoints accessible in production

How to prevent it:

• Treat infrastructure configuration as code — version-controlled, reviewed, and tested
• Run automated configuration scanning as part of your CI/CD pipeline
• Apply the principle of least privilege to every service account and IAM role
• Disable or remove all debug and development endpoints before deploying to production
• Conduct regular environment audits

5. Sensitive Data Exposure

Custom applications often handle data that carries significant regulatory and reputational risk: personal information, payment details, health records, intellectual property. Exposure can happen at rest, in transit, or through logging.

Common failures:

• Storing sensitive data unencrypted in databases or file systems
• Logging request bodies that contain passwords or tokens
• Returning more data than necessary in API responses (over-fetching)
• Using HTTP instead of HTTPS for internal service communication

How to prevent it:

• Encrypt sensitive data at rest using AES-256 or equivalent
• Enforce TLS 1.2+ for all communications, including internal service-to-service calls
• Audit your logging pipeline — ensure no sensitive fields are captured
• Apply data minimisation: only collect and store what you genuinely need
• Implement field-level encryption for the most sensitive attributes

6. Vulnerable and Outdated Dependencies

Custom software is built on open-source libraries. Those libraries have their own vulnerabilities, and they're discovered continuously. A dependency that was safe when you shipped version 1.0 may be a critical CVE by version 1.1.

Many teams have no process for tracking dependency health. They ship, move on, and never look back until something breaks.

How to prevent it:

• Integrate automated dependency scanning (Dependabot, Snyk, or similar) into your CI pipeline
• Set a policy for how quickly critical CVEs must be patched — 24 hours is a reasonable target
• Pin dependency versions in production and review updates deliberately
• Audit transitive dependencies, not just direct ones

7. Insufficient Logging and Monitoring

This one doesn't cause breaches directly — but it determines how long a breach goes undetected and how much damage it causes. The average time to detect a breach is still measured in months. Comprehensive logging cuts that dramatically.

Custom applications often have minimal logging because it wasn't a requirement in the original spec. Authentication events, privilege escalations, and data access patterns go unrecorded.

How to prevent it:

• Log all authentication events: successes, failures, lockouts, and password resets
• Log all access to sensitive resources with user identity and timestamp
• Set up alerting for anomalous patterns: unusual access volumes, off-hours activity, repeated failures
• Centralise logs in a tamper-resistant system separate from the application

Building Security In, Not Bolting It On

The most expensive security fix is the one you make after a breach. The second most expensive is the one you retrofit into a system that wasn't designed with security in mind.

At XcodeFactory, security is part of our development process from the first line of code — not a checklist at the end. Threat modelling, secure code review, and automated scanning are standard practice on every project we build.

If you're running custom software and aren't confident in its security posture, a structured audit is the right starting point. The vulnerabilities above are common, well-understood, and entirely preventable with the right approach.