Security

Security in Web Applications: What Clients Should Ask Developers

Empower yourself with the right questions to ask your development team about web application security. Learn what matters most and how to ensure your software is protected against modern threats.

DevWebLab Team
14.08.2025
10 min read

Security breaches make headlines regularly, and the consequences can be devastating - financial losses, damaged reputation, legal liability, and lost customer trust. Yet when commissioning web application development, many business owners feel uncertain about how to evaluate security measures. You don't need to be a security expert to ask the right questions, but knowing what to ask can make the difference between a secure application and a vulnerable one.

This guide will help you understand the critical security questions you should be asking your development team, what their answers should include, and why each aspect matters for protecting your business and your users.

Understanding Authentication: Who Gets Access?

One of the first questions to ask is how the application will verify user identities. Authentication is the process of confirming that users are who they claim to be, and it's your first line of defense against unauthorized access.

What to ask: "How will user authentication be implemented, and what security standards will you follow?"

Strong authentication systems use proven methods rather than custom solutions. Look for answers that mention established protocols like OAuth 2.0 for social login integration, or JSON Web Tokens (JWT) for API authentication. For enterprise applications, developers might mention SAML for single sign-on capabilities.

Password handling deserves special attention. Passwords should never be stored in plain text - ever. Your developers should explain that they'll use strong hashing algorithms specifically designed for passwords, like bcrypt or Argon2. These algorithms make it computationally expensive for attackers to crack passwords even if they somehow obtain your database.

Multi-factor authentication (MFA) adds an extra security layer by requiring users to provide two or more verification factors. Ask whether MFA is included in the project scope, especially for applications handling sensitive data or financial transactions. Modern frameworks like Spring Security provide built-in support for these features, making implementation straightforward.

Authorization: Controlling What Users Can Do

Authentication confirms who someone is, but authorization determines what they're allowed to do. Even legitimate users shouldn't have access to everything in your system.

What to ask: "How will you implement role-based access control, and how can we modify permissions as our needs change?"

Effective authorization systems use role-based access control (RBAC), where users are assigned roles like "administrator," "manager," or "viewer," and each role has specific permissions. The system should enforce these permissions consistently across all application areas - both in the user interface and at the API level.

Your developers should be able to explain how permissions will be checked before sensitive operations occur. It's not enough to hide a "delete" button from users who lack permission - the underlying API must also verify that the user making the request has the necessary authorization. This prevents attackers from bypassing the interface and directly calling protected functions.

Ask about flexibility too. Your business needs will evolve, and you may need to create new roles or adjust existing permissions. The system should accommodate these changes without requiring extensive code modifications.

Data Protection: Safeguarding Sensitive Information

Your application will likely handle data that needs protection - customer information, financial records, health data, or proprietary business information. How this data is protected both in transit and at rest is crucial.

What to ask: "How will sensitive data be encrypted during transmission and storage, and what compliance standards will you follow?"

All data transmitted between users and your servers should be encrypted using HTTPS with modern TLS protocols. This prevents eavesdropping and man-in-the-middle attacks. Your developers should configure this properly, including HTTP Strict Transport Security (HSTS) headers that ensure browsers always use encrypted connections.

For data storage, ask specifically about sensitive information like passwords, payment details, or personal identifiers. Beyond password hashing, other sensitive data might need encryption at rest. Your developers should explain their approach to key management - how encryption keys are generated, stored, and rotated.

If your application handles payment information, ask about PCI DSS compliance. For healthcare data, HIPAA requirements may apply. For European users, GDPR mandates specific data protection measures. Your development team should understand relevant regulations and implement appropriate safeguards.

Input Validation: Preventing Malicious Data

Many security vulnerabilities stem from applications trusting user input without proper validation. Attackers exploit this trust to inject malicious code or manipulate application behavior.

What to ask: "How will the application validate and sanitize user input to prevent injection attacks?"

SQL injection remains one of the most dangerous vulnerabilities, allowing attackers to manipulate database queries and potentially access or destroy data. Your developers should never construct database queries by concatenating user input with SQL strings. Instead, they should use parameterized queries or ORM frameworks that handle escaping automatically.

Cross-site scripting (XSS) attacks inject malicious scripts into web pages viewed by other users. Protection involves validating input and properly escaping output before displaying it. Modern frameworks provide built-in defenses, but developers must use them correctly.

Ask about server-side validation. While client-side validation improves user experience, it's not a security measure - attackers can bypass it entirely. All validation must occur on the server, where you control the environment.

Session Management: Maintaining Secure User Sessions

When users log in, the application creates a session to track their authenticated state. Poor session management can allow attackers to hijack these sessions and impersonate legitimate users.

What to ask: "How will user sessions be managed securely, and what protections prevent session hijacking?"

Secure session management includes several components. Session identifiers should be randomly generated, long enough to prevent guessing, and transmitted only over encrypted connections. They should also be marked as "HttpOnly" and "Secure" to prevent JavaScript access and ensure transmission only over HTTPS.

Sessions should have reasonable timeouts - short enough to limit exposure if someone leaves their computer unattended, but long enough to avoid frustrating legitimate users. Ask about both idle timeouts (inactivity periods) and absolute timeouts (maximum session duration regardless of activity).

When users log out, their session should be completely invalidated on the server side. Simply clearing the client-side token isn't sufficient - the server must refuse to honor that session identifier if it's somehow reused.

API Security: Protecting Your Backend Services

Modern web applications often communicate with backend APIs to fetch data and perform operations. These APIs need protection just as much as the user-facing portions of your application.

What to ask: "How will APIs be secured against unauthorized access and abuse?"

API authentication should use token-based approaches rather than passing credentials with every request. OAuth 2.0 or JWT tokens are common choices. Each API endpoint should verify that the caller is authenticated and authorized to perform the requested operation.

Rate limiting prevents abuse by limiting how many requests a user can make within a time period. This protects against denial-of-service attacks and automated scraping attempts. Ask how rate limiting will be implemented and whether limits will be configurable for different user types.

For sensitive operations, consider asking about additional protections like request signing, where requests include cryptographic signatures proving they haven't been tampered with. This is particularly important for financial transactions or critical business operations.

Third-Party Dependencies: Managing External Code

Modern applications rely on numerous libraries and frameworks. While these accelerate development, they can also introduce vulnerabilities if not managed properly.

What to ask: "How will you manage third-party dependencies and keep them updated for security patches?"

Your developers should explain their process for selecting dependencies. Reputable, actively maintained libraries are safer choices than obscure or abandoned projects. They should also describe how they'll track known vulnerabilities in dependencies.

Automated tools can scan your application's dependencies and alert developers when vulnerabilities are discovered. Ask whether such tools will be integrated into the development workflow. For Java applications, tools like OWASP Dependency-Check or Snyk can identify vulnerable dependencies and suggest updates.

Security patches need to be applied promptly. Ask about the process for reviewing and deploying updates when vulnerabilities are announced. A good development team has procedures for emergency patches outside the normal release cycle.

Error Handling: Failing Securely

How your application handles errors can reveal information useful to attackers or create vulnerabilities. Proper error handling is both a security measure and a quality consideration.

What to ask: "How will the application handle errors without exposing sensitive information?"

Error messages shown to users should be helpful without revealing system details. Messages like "Username or password incorrect" are better than specifying which was wrong, as the latter helps attackers identify valid usernames. Stack traces and internal error details should never be shown to end users.

However, detailed error information should be logged securely for developers to diagnose issues. Ask how errors will be logged, where logs will be stored, and who can access them. Logs themselves can contain sensitive data, so they need protection.

The application should fail securely - if an error occurs during a permission check, access should be denied rather than inadvertently granted. This "fail-safe" approach prevents security bypasses due to unexpected error conditions.

Security Testing: Finding Vulnerabilities Before Attackers Do

Even with secure coding practices, vulnerabilities can slip through. Security testing helps identify and fix issues before your application goes live.

What to ask: "What security testing will be performed, and will there be penetration testing before launch?"

Automated security testing tools can identify common vulnerabilities like those listed in the OWASP Top 10 - a regularly updated list of the most critical web application security risks. Ask whether these tools will be integrated into the development process to catch issues early.

Penetration testing involves security experts attempting to exploit your application as an attacker would. This testing often reveals issues that automated tools miss. While it adds cost, it's valuable for applications handling sensitive data or facing significant security threats.

Code reviews with security focus help catch vulnerabilities that might be missed by automated tools. Ask whether security will be a specific focus during code reviews and whether team members have security training.

Monitoring and Response: Detecting and Addressing Security Issues

Security doesn't end at launch. Ongoing monitoring helps detect attacks and suspicious activity, while an incident response plan ensures your team can act quickly if issues arise.

What to ask: "What security monitoring will be in place, and what's the plan if a security incident occurs?"

Security monitoring includes watching for suspicious login attempts, unusual API usage patterns, or other indicators of attack. Ask how these will be tracked and what thresholds will trigger alerts. For applications with significant security requirements, consider security information and event management (SIEM) systems.

Your development team should have an incident response plan outlining steps to take if a security breach occurs. This includes identifying the issue, containing the damage, notifying affected parties, and implementing fixes. While you hope never to need it, having this plan ready is crucial.

Ask about the process for security updates after launch. How quickly can patches be developed and deployed? What communication will you receive about security issues? Understanding this process helps you assess the long-term security posture of your application.

Compliance and Standards: Meeting Legal Requirements

Depending on your industry and users, various regulations may mandate specific security measures. Your development team should understand applicable requirements and build compliance in from the start.

What to ask: "What compliance requirements apply to our application, and how will you ensure we meet them?"

Different industries face different regulations. Healthcare applications must comply with HIPAA, financial services with PCI DSS or SOX, and any application serving European users with GDPR. Your developers should identify relevant regulations early in the project.

Compliance isn't just about technical controls - it also involves policies, procedures, and documentation. Ask how compliance requirements will be documented and what evidence will be provided to demonstrate adherence to standards.

Some organizations seek third-party security certifications like SOC 2 or ISO 27001. While these aren't always necessary, understanding them helps you evaluate whether they'd benefit your business and whether your application's security posture would support certification.

Documentation: Recording Security Measures

Good security documentation helps maintain security over time and enables informed decisions about system changes.

What to ask: "What security documentation will be provided with the application?"

Security documentation should include architecture diagrams showing how components interact and where security controls exist. It should document authentication and authorization mechanisms, encryption methods, and any security-related configuration.

For your own team members who'll maintain the application, documentation should explain security considerations for common maintenance tasks. This might include how to add new user roles, configure API access, or review security logs.

Ask for a security guide outlining best practices for deploying and operating the application. This should cover topics like secure configuration, key management, and recommended monitoring practices.

Building a Security-Conscious Partnership

The best security comes from partnerships where both client and developer prioritize protection. By asking these questions, you demonstrate that security matters to your business and expect it to be taken seriously.

Don't be intimidated by technical terminology - good developers can explain security concepts in business terms. If answers feel evasive or dismissive, that's a red flag. Security should be a core consideration, not an afterthought or an optional add-on.

Remember that security is an ongoing process, not a one-time achievement. Technology evolves, new vulnerabilities emerge, and your application will need updates over its lifetime. Choose development partners who view security as a continuous commitment and are prepared to support your application's security needs long term.

Taking Action: Your Security Checklist

As you evaluate development teams and review project proposals, use these questions as a framework for discussion. You don't need to ask every question in every conversation, but covering these topics ensures comprehensive security consideration.

The right development team will welcome these questions and provide clear, confident answers. They'll appreciate working with a client who values security and will be proactive about implementing protections that keep your application, your business, and your users safe.

In today's digital landscape, security isn't optional - it's essential. By asking the right questions and ensuring your development team takes security seriously, you're protecting not just your application, but your business reputation, customer trust, and long-term success.