© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2022
M. BakerSecure Web Application Development https://doi.org/10.1007/978-1-4842-8596-1_14

14. Further Resources

Matthew Baker1  
Kaisten, Aargau, Switzerland

We’d love it if this book were the only thing you needed to read about web application security. Unfortunately, it is not, and the reason is that things change. New technologies come out, introducing new vulnerabilities. New versions of software are released, with new bugs creating threats. And hackers are always on the lookout for vulnerabilities that haven’t been discovered yet.

Knowing how to write a secure web application is the first step. The next step is staying up to date with vulnerabilities and trends and keeping your new and existing applications secure. In this chapter, we will look at some useful resources for staying up to date. We will also summarize what we have learned.

14.1 Vulnerability Databases

Fortunately for us, there are many people looking for vulnerabilities in software: good guys as well as bad. When vulnerabilities are found in software packages, they are often unloaded to vulnerability databases.

The CVE project, which stands for Common Vulnerabilities and Exposures, is an effort to classify known vulnerabilities in a consistent way and catalogue them in an online, searchable database. It was launched by the MITRE Corporation in 1999 and is available at https://cve.mitre.org. In 2005, the US National Institute of Standards and Technology (NIST) launched the National Vulnerability Database, or NVD. The two databases are now fully synchronized, with NVD providing additional information and search features to CVE entries. It is available at https://nvd.nist.gov.

A CVE entry is assigned a CVSS score. CVSS stands for Common Vulnerability Scoring System. A CVSS score is a numerical value between 0 and 10 indicating how severe a vulnerability is. It has been through several versions, the latest at the time of writing being 3.1. NIST provides a calculator for deriving the score, based on characteristics of the vulnerability.1 The qualitative rating for CVSS 3.0 and 3.1 is given in Table 14-1.
Table 14-1

The CVSS scoring system

CVSS Score



No vulnerability









Another CVE database is https://cvedetails.com, which provides browsable lists categorized by vendor, product, and CVSS score.

As an example, searching the NVD for the term ”slowloris” yields 13 matches. One of these, CVE-2007-6750, is for the Apache web server. The entry that has a URL

explains that it affects versions 1.0 through to 2.1.6 of the web server.

GitHub also has a security advisory database. It includes CVEs as well as advisories originating from GitHub itself. It is available at https://github.com/advisories.

14.2 News and Alerts Sites

Vulnerability databases excel at providing comprehensive sources of concise and searchable data on vulnerabilities. However, they are less suitable for following regularly to learn of new dangers. News and alert sites provide exactly this.

There are a number of news sites dedicated to IT security. Among the better and more established ones are

Alert sites provide a more concise feed of security updates. Users can subscribe to receive emails or an RSS feed when new alerts are released. The US Government’s Cybersecurity and Infrastructure Security Agency (CISA) is one example. Its alerts can be browsed at www.cisa.gov/uscert/ncas/alerts, and you can subscribe to receive emails or an RSS feed.

The Canadian Government’s Canadian Centre for Cyber Security also has a good alert feed. It is browsable at https://cyber.gc.ca/en/alerts-advisories, and you can subscribe to its RSS feed. It collects advisories from vendors such as Apache, Adobe, and Microsoft, saving readers the effort of following each one.

14.3 The OWASP Top Ten

We mentioned OWASP in Chapters 3 and 9. OWASP (the Open Web Application Security Project in full) in a nonprofit organization for promoting web application security. Among their activities, they maintain a Top Ten list of web application vulnerabilities. It is updated every five years or so, most recently (at the time of writing) in 2021. It can be browsed at
In this section, we will look at their current top vulnerabilities. They have all been covered in the previous chapters of this book, but monitoring their Top Ten is useful to understand growing (and shrinking) threats and what are the most common. The 2021 list is
  • A01:2021–Broken Access Control

  • A02:2021–Cryptographic Failures

  • A03:2021–Injection

  • A04:2021–Insecure Design

  • A05:2021–Security Misconfiguration

  • A06:2021–Vulnerable and Outdated Components

  • A07:2021–Identification and Authentication Failures

  • A08:2021–Software and Data Integrity Failures

  • A09:2021–Security Logging and Monitoring Failures

  • A10:2021–Server-Side Request Forgery

Broken Access Control

This was number five in 2017. Some common vulnerabilities in this category include
  • Pages being viewable or editable by people who are unauthorized

  • Being able to bypass security by modifying a URL

  • Access control missing for API calls, especially POST, PUT, and DELETE methods

  • Poor access tokens, such as being able to modify JWTs

  • Misconfigured CORS

For addressing these vulnerabilities, see Chapters 6 and 8.

Cryptographic Failures

Cryptographic Failures has moved from the third place to the second. It was previously called Sensitive Data Exposure. This category includes
  • Transmitting data in cleartext

  • Using old, insecure encryption and hashing algorithms (e.g., MD5 and SHA-1)

  • Allowing HTTP connections rather than enforcing HTTPS

  • Not validating certificates

  • Poor random number generators

We covered encryption, hashing, and certificates in Chapter 4 and discussed how to enforce HTTPS in Chapter 5.


Injection was previously in the top position. It slid down to the third place largely because frameworks have closed a number of these vulnerabilities in their default configuration.

This category includes cross-site scripting, SQL injection, command injection, code injection, and any other injection vulnerabilities where user-supplied code is executed in some way on the server without sanitizing and validation. We discussed this category in Chapter 7.

Insecure Design

This category is new for 2021. It refers to flaws in design, as opposed to flaws in implementation. Threat modelling, which we covered in Chapter 3, helps greatly in identifying trust boundaries and attack surfaces. Using established patterns and, where possible, well-scrutinized frameworks and libraries helps prevent insecure design patterns creeping into code.

Poorly designed APIs are also common. Keeping to correct REST principles, as discussed in Chapter 6, helps make these secure.

Security Misconfiguration

Up one place from 2017, this broad topic includes
  • Unnecessarily open ports and enabled features

  • Default accounts and passwords

  • Not applying security patches to third-party components

  • Absent security headers such as X-Frame-Options and CSP

We covered these issues as they apply to server components in Chapter 5. We discussed security headers in Chapter 8.

Vulnerable and Outdated Components

This category moved up from the ninth place in 2017 to the sixth in 2021. There is some overlap with Security Misconfiguration, but this category refers specifically to using third-party components that have known vulnerabilities. We discussed the use of third-party components in Chapter 13. Subscribing to security alerts, searching vulnerability databases, and reading security news sites are all good ways to stay informed of newly discovered vulnerabilities. And, of course, patches should be applied immediately when they fix vulnerabilities.

Identification and Authentication Failures

Identification and Authentication Failures has dropped from the second place to the seventh, largely because good standards and components are now available and enabled by default in many popular frameworks.

This category covered insufficiently secure authentication and authorization subsystems. Examples include
  • Permitting weak passwords

  • Password policies and storage permitting brute-force attacks

  • Flaws in password recovery patterns

  • Storing passwords as plaintext or weakly hashed

  • Exposed session IDs

We covered these topics in Chapters 9, 10, and 11.

Software and Data Integrity Failures

This category is new for 2021. It refers to lack of integrity checking, allowing vulnerable or modified code to find its way into productive systems. This can include
  • Linking JavaScript code without checking its integrity

  • Lack of integrity checking or oversight in CI/CD pipelines

SRI and nonces, as described in Chapter 8, help with the former; the supply chain security techniques discussed in Chapter 13 are designed to address the latter.

Security Logging and Monitoring Failures

This category moved up one position from 2017. We discussed it in Chapter 12. Hackers can be quick at discovering new web services and will use systematic techniques to find vulnerabilities. If they gain access, they will often hide their tracks, for example, by deleting logs. Thorough logging and active monitoring are crucial in maintaining a secure web application and identifying security violations before harm is done and evidence deleted.

Server-Side Request Forgery

Server-Side Request Forgery is new for 2021. We discussed it in Chapter 7. It occurs when a server fetches a URL that is supplied by the user, without first validating and sanitizing it. As well as potentially facilitating sending data to a malicious server, it may provide a way for hackers to evade a firewall as the URL is fetched from within the corporate network.

14.4 Summary

Web application security, like IT in general, is constantly evolving. In this book, we have covered the major aspects of making your application secure. However, it is important to understand why each of the techniques protects your application and what their limitations are. Writing a secure application is not about cutting and pasting boilerplate code. Rather, it is understanding your threats, your users’ requirements, and the toolkit available to eliminate or mitigate those risks while still meeting your other requirements.

In this last section, we give our own top ten guide of things you should do when creating a web application:
  1. 1.

    Plan your application end points. Make sure you are using HTTP methods correctly, for example, not making changes in GET request. If implementing a REST API, follow the guide in Chapter 6.

  2. 2.

    Map your trust boundaries and attack surface (see Chapter 3). If you do this at the beginning of development, it is easier to make it complete. Keep it up to date as you develop your application.

  3. 3.

    When installing components on your server, block all unneeded ports and turn off all unneeded services and features (e.g., FTP). Use a host firewall and/or TCP Wrappers. We covered these topics in Chapter 5.

  4. 4.

    Use established, well-scrutinized packages and frameworks in preference to writing your own code, when there are security implications. It’s easy to get security code wrong.

  5. 5.

    Validate all user input. Consider anything that comes from the user or browser to be unsafe. Validate types (e.g., that an integer field doesn’t contain text). Escape HTML and use prepared statements for SQL. See Chapter 7 for a discussion on user input.

  6. 6.

    Get a TLS certificate and permanently redirect HTTP to HTTPS so that no data is accepted or transmitted unless encrypted (see Chapter 5).

  7. 7.

    Make your application as restrictive as possible. Use CSRF tokens. Make cookies Strict if your application allows it, Lax otherwise. Set HttpOnly and Secure unless infeasible. Don’t add CORS unless needed and, if you do, keep it as restricted as possible. Use CSP to only allow what’s needed. See Chapter 7 for cookies and Chapter 8 for CSRF tokens, CORS, and CSP.

  8. 8.

    Use well-established authentication and authorization patterns, preferably libraries or frameworks that have it already implemented. Don’t use deprecated, easy-to-crack algorithms. We discussed this topic in Chapters 10 and 11.

  9. 9.

    Make sure you have an effective logging and monitoring strategy. Consider using alerts if you do not have someone always monitoring a dashboard. See Chapter 12 for a discussion on logging.

  10. 10.

    And, to quote Motörhead, don’t forget the joker: hacking people is often easier than hacking an application (see Chapter 13). Be aware of what information you make public (e.g., through your website or job ads). Make sure developers and other staff are aware of potential social engineering attacks. Understand what passwords and access tokens are on developers’ and ops staff’s devices. Encrypt disks on mobile devices. Put passwords on SSH keys. Make sure access tokens can be invalidated easily if necessary.


Above all, learn from your mistakes. Even the best development teams let vulnerabilities in occasionally. The important thing is that you can identify and fix them quickly and, next time, can make an even more secure application. Good luck on your journey!

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.