Digital adoption is only increasing in today’s world. It brings with it the challenges of safeguarding financial and personal data against potential threat actors. Including web application security best practices during application development can patch some of these holes and ensure the applications adhere to security standards and are free of vulnerabilities.

The Impact of Threat Actors

First, it’s important to note the ramifications of attacks. Threat actors’ motives may range from economic benefit to stealing user data, causing denial of service, tarnishing the image of corporations or simply getting a thrill.

Such attacks can cause the loss of precious data from customers and end-users, along with financial loss, service disruption, brand damage or a boost for rival groups.

For example, Adobe announced threat actors had breached its IT system in October 2013. They stole personal information from 2.9 million accounts, including logins, passwords, names, credit card numbers and expiration dates.

A year later, Yahoo! announced it had suffered a cyber attack that affected 500 million user accounts. This was the largest breach of personal data directed against a single company in history. 

Equifax, an American credit reporting company, revealed (six weeks after the fact) that it had suffered a cyberattack over the course of a number of months. Detected in July 2017, it contained the personal data (names, birth dates, social insurance numbers and driver’s license numbers) of 143 million customers from the U.S., Canada and Britain, as well as 200,000 credit card numbers.

Most recently, 130 high-profile Twitter accounts were compromised by outside parties to promote a bitcoin scam on July 15, 2020. 

Important Web Application Security Best Practices

It is best to include web application security best practices during the design and coding phases. Otherwise, you’ll have to rely on finding and fixing openings at later stages or after release. Follow these best practices during the various phases of development.

Design Phase

Consider securing your work as early as the design phase. Fixing loopholes in this phase saves effort and cost, plus reduces time to market. If the team is not aware of the concept of secure design, they can use a process called threat modeling (TM) with the help of a career security team. This team will assess whether the design of the product is secure and compliant.

In this process, the TM and the development teams, along with security architects, have a series of discussions. The TM team asks a range of questions to understand if the design team has taken risks into account. For example, did they implement encryption for sensitive data at rest and motion? Have they mandated strong passwords? Did they implement multiple levels of user privileges? Is the application performing input validation? Performing TM helps with efficient design and prevents the need for redesigns at later stages to fix loopholes.

Development Phase

Developers working on applications should be trained on the Open Web Application Security Project’s OWASP Top 10 and the SANS Institute’s SANS web application security checklist. This will help them be aware of issues that need to be avoided during coding. It is best to always use secure frameworks rather than writing one’s own code. You should also make sure to use the latest versions of libraries and third-party codes. Always check for openings in third-party and open-source software. Fix these before adding them to the code.

Secure Coding

During secure coding, your team should follow these web application security best practices to avoid weaknesses in the code:

Input Checks
Make sure to validate input fields on both the server and client side. Malicious processes can easily bypass it at the client side. For cases where a malicious user has bypassed the client-side validation, the server side will handle it.

Always perform boundary checks to prevent buffer overflow problems. Buffer overflow can open the code up to many types of risks, such as denial of service and remote code injection. Hence, performing boundary checks for input fields can prevent such risks.

Adopt whitelisting instead of blacklisting to check input fields. The blacklisting approach can make it difficult to restrict malicious inputs. In turn, it may leave the door open for threat actors. Using whitelisting to allow only the required type of characters will help in preventing many types of input validation risks.

Command Injection
You should make sure the code avoids running commands directly from the input value received. If it does, you may find openings like operating system (OS) command injection. In this case, the threat actor can run OS commands on the server by injecting them in the input fields that have not been properly sanitized. Even in cases where it may be required to run commands, always run with the least privilege required.

SQL Injection
Structured query language (SQL) injection is one of the top risks you might encounter. In this type of attack, a SQL statement enters the input fields, which results in running these statements in the database (DB). This reveals the DB contents and allows for dumping of the entire DB or inserting malicious values in the DB. To avoid such risks, use prepared statements for the DB query instead of forming a query directly from user input. Using stored procedures is also a good practice.

Other Web Application Security Best Practices
Many security headers have been defined to prevent issues, such as cross-site scripting (XSS), clickjacking and other issues. Using headers is an easy way to provide a minimum level of safety for such issues and provide a defense-in-depth barrier against those risks. Some common types of security headers are HTTP strict transport security (HSTS), X-XSS-protection, X-content-type-options, X-frame-options and content-security-policy.

In cases where a file upload option is provided to the user, restrict the type of file being uploaded to only the expected type. Make sure to require that the file extension and the content of the file being uploaded are verified. In addition, perform a scan on the uploaded file to check for any malicious content.

Avoid having a uniform resource locator (URL) or path input field. Using the path input directly in the code can lead to risks such as local file inclusion, remote file inclusion, server-side request forgery and unvalidated redirect and forward. Even if it is required to have paths and URLs in input value, use proper whitelisting to prevent any misuse.

Encryption

Encryption is one of the most important aspects of securing your work. Make sure it is in place for data in transit and at rest, taking special care when data includes sensitive information. Always use HTTPS and never allow access over HTTP. It is important to use well-known encryption techniques instead of trying to implement your own. Along with encryption, check that data is secure using techniques, such as hashing.

While using encryption, one should avoid known weak algorithms, ciphers or versions. Even when storing sensitive data in log files or DB, the data needs to be encrypted.

Testing for Passwords and Logins

Make sure the passwords your users choose are complex. The password should be a minimum of eight characters (longer is better) and contain a mix of upper, lower and special characters. This will make brute force and dictionary attacks more difficult to execute. To further improve this step, use two-factor authentication. In addition, you should implement an account lockout when the system detects the maximum number of password attempts.

In order to make sure only authorized users get in, use graded, privilege based access with least privilege for the default role. Use role-based access to resources in order to ensure access to specific resources is only granted for users with the required privilege.

Web Application Security Tools

By following web application security best practices during the design phase, the security posture of the application can be enhanced. You can add to this base with various web application security testing methods to ensure that security is at the highest possible level before deploying your work.

DevSecOps
Integrate security practices within the DevOps process by performing scans during the build process.

SAST
Static application security testing (SAST) is a source-code scanning method. You can find many web application security tools that can identify security risks in the code with SAST. However, SAST can give a lot of false positives, so carefully analyze and filter the results so that you can fix the genuine issues.

DAST
Dynamic application security testing (DAST) uses remote testing of deployed and running code to find openings. The DAST tools send lots of requests with malformed packets to the code with the intention of finding holes. Along with this, analyze the results for actual defects. Integrate DAST into the build process along with SAST.

Penetration Testing
Penetration testing, an advanced security testing method, uses a combination of dynamic scanning tools and manual exploitation techniques to find openings. With this, you can try to exploit them to gain access, steal data, compromise users or cause service disruption the way a real threat actor would. This is a more advanced technique compared to SAST and DAST, and it can unearth more risks in the application when performed by a skilled team.

Building in Safety From Day One

Security needs to be built into the application life cycle, not just added as an afterthought. By following security best practices during the design and development phases, developers and architects can ensure that their applications will be safer from attacks and safeguard their customers’ data.

Along with these practices and processes, you can engage a qualified team to validate and certify the posture of your work using various testing methods. Together, these best practices will go a long way in securing new projects against cyberattacks and creating a sense of trust with customers.