Web Application Security

Is It Really True That Application Security has “Best-Practices”?

Application Security professionals commonly advocate for “best-practices” with little regard for the operational environment. The implication of a “best practice” is they are essential for everyone, in every organization, and at all times. Commonly cited “best-practices” include, but are not limited to, software security training, security testing during QA, threat modeling, code reviews, architecture analysis, Web Application Firewalls (WAF), penetration-testing, and a hundred other activities.

Sure, all these “best-practices” sound like good ideas. And any good sounding “application security” idea must be a “best-practice” right? Not so fast. Watch this, I’ll create a new “best-practice” right now: Website Bug Bounty programs. See how easy that was! Google does it. So does PayPal, Mozilla, Facebook, and Etsy. Now everyone must do it! Seriously though, more thoughtfulness is required.

After more than a decade working in the Application Security industry, I’m fairly confident there are few, if any, “best-practices” — that is to say, activities universally effective and investment worthy no matter the current environment. I’m convinced that different application security activities, including those listed above, are best suited in different scenarios. In fairness, I must admit that I’ve a limited amount of data that backs up my assertion, but at the same time it’s probably more data than those blindly advocating “best-practices” have to offer.

I’d like to share my thought process and support my opinions by laying out a few example scenarios. The following are vulnerability statistics descriptions of real-world websites taken over a period of time. These scenarios may be familiar to anyone with more than a few years of application security experience.

Website A

Produces a high rate of new vulnerabilities, about 20 each month, largely dominated by Cross-Site Scripting (XSS). When vulnerabilities are identified in production, the development team fixes nearly every one in under 24 hours. The net result is Website A is an industry laggard in vulnerability volume, but a leader in time-to-fix and remediation rate.

Given this scenario, and if you knew nothing else about the organization responsible for the website, what application security “best-practices” would you recommend they adopt first to improve their security posture?

My Recommendations

• Look into the development framework in use. Perhaps the output encoding APIs are nonexistent, imperfect, not well advertised to developers internally, and/or their use is not strictly mandatory.

• An internal security QA process should be created, or improved upon, to catch the XSS vulnerabilities prior to production release.

Addressing either one of these potential gaps could seriously curtail the XSS problem, quickly too! How close were your recommendations to mine? The same, way different, or somewhere in between? Let’s hear it in the comments.

Which “best-practices” would you not recommend, at least initially?

I’d recommend holding off on:

• Threat modeling is great for spotting missing security controls during the application design phase, but given the type of vulnerabilities in this case (XSS), and the organizations ability to patch them quickly, the problem appears more on the implementation side rather than design.

• The statistics show XSS vulnerabilities are capable of being fixed quickly when identified, indicating that they development team knows what the issue is and how to fix it. So, software security training for developers might help, but only if the programmers have been provided effective anti-XSS tools and for whatever reason aren’t using them consistently.

• WAFs can act as a virtual patches for websites experiencing lengthy time-to-fix metrics and low remediation rates, but that’s not what the metrics are showing us here.

In the next statistics scenario, the situation is slightly varied…

Website B

Experiences roughly 100 serious vulnerabilities a year, a large portion of which are XSS, but also a nontrivial number of SQL Injection, Insufficient Authentication, and Insufficient Authorization issues exist. When vulnerabilities are brought to the attention of the development team, the Insufficient Authentication and Insufficient Authorization issue are fixed consistently and comprehensively within a week or two. On the other hand, XSS and SQL Injection issues remain exposed for several months and do not get fixed often.

Given these statistics, what “best-practices” would you recommend first? The same as Website A or different?


• Insufficient Authentication and Insufficient Authorization issues are of low volume and taken care of quickly, but the more esoteric vulnerabilities such as XSS and SQL Injection are not. This says the odds are developer education is lacking in the latter two vulnerability classes. To address this focus a software security training program on those vulnerability classes, XSS and SQL Injection, placing emphasis on understanding the risks and proper defensive coding techniques.

• Deploy a Web Application Firewall, particularly a product capable of automatically integrating vulnerability results to create virtual-patch rules. This is important so that while the developers come up to speed on XSS and SQL Injection, the IT operations team can be engaged to help mitigate the risks they pose in a timely fashion.

• While Insufficient Authentication and Insufficient Authorization are fixed quickly, the mere fact that they exist could lead to the conclusion that a Threat Modeling process is could be helpful and perhaps some security QA to test for various abuse cases.

Comment below if you agree or disagree.

Website C

Very few vulnerabilities, maybe only 1 XSS per month, make it through the software development life-cycle (SDL) to production. WHEN XSS issues are identified, they are fixed, and fixed extremely quickly, taking no more than a day. But, vulnerabilities don’t get remediated often. In fact, Website C’s annual remediation rate is under 25%.

With these statistics in mind, what “best-practices” should prioritized? The same as Website A and Website B or different?

My initial assumption would be that the organization has a vulnerability prioritization problem and/or lack of development resources where the investment in revenue generating features is placed ahead of security fixes. And for them, perhaps that’s the right decision. If so…


• In the near-term, like in Website B, deploy a Web Application Firewall with virtual-patch integration capability. If the vulnerabilities are to remain publicly exposed in the code for an extended period of time, as a business decision, the bar to exploitation higher should be pushed higher.

• For a longer-term plan, engage experienced consulting firm that specializes in code remediation. That way the organizations core development team can stay focused driving features while the current pool of vulnerabilities is simultaneously taken care of.


• The metrics obviously show that the development team generates very few vulnerabilities. This is probably because they either are well-versed in XSS and other classes of attack, have the proper tools, and/or an effective QA process. If so, it also means investing in software security training for developers and QA process improvement probably isn’t going to make a huge impact on poor remediation rates.

Agree or disagree with the guidance? Sound off in the comments.


We could continue forever discussing all the possible varied statistical scenarios one might encounter in application security. I maintain that application security defense must be adaptive, situationally aware, and inline with the interests of the business. Therefore, while a “best-practice” might sound like good ideas, it must be applied at the right time and place. This is a big reason why customers of WhiteHat Security measurably improve their security posture over time. As the saying goes, anything measured tends to improve.

The ability to capture vulnerability statistics, on an ongoing basis, provides invaluable insight into how to prioritize organizational action that has the best chance to improve the outcomes. Without knowing where the gaps are in the application security program ahead of time, what else can be done except guess what “best-practice” might help, which unfortunately is what most do so. When you don’t have to guess, organization can continue investing in activities that are measurable returning value, divest in those that don’t, and better apply those scarce application security resources.

  • fatbloke

    Aside from the fact that ‘best practice’ (IMHO) is a misnomer, because what could be considered ‘best practice’ in one scenario may be completely idiotic in another (and therefore perhaps we should term such things ‘good practice’), you have a vested interest here period to sell product. Thus, any conclusions you draw are tainted with the realisation that most of the solutions you express require deployment of a WAF.

    The fact is, a lack of consideration of security basics is a case in point here. The fact that XSS or SQL Injection vulnerabilities sneak through as part of development activities implies that appropriate coding techniques (such as input validation, output encoding and parameterised queries) are not being used in a consistent manner. Coupled with appropriate security testing prior to deployment, fixing these basic problems would remove the need for any deployment of a ‘point solution’.

    • http://www.whitehatsec.com/ Jeremiah Grossman

      @fatbloke I do not hide the fact that I’ve a product to sell. In fact, because of the product I sell, website security measurement, we can make more informed decisions about what works and what does not. There might be other ways to do this that I’m happy to discuss, but this is just how I approach the space.

      Your core point implies that there exists a known process on how to make vulnerability-free code, or even close to it, which of course there isn’t. Software bugs, and hence security vulnerabilities, will always slip through to production no matter how much upfront work was put in. The business must then decide if they’d their developers should work on revenue generating features or instead fix security issues. If they decide NOT to fix the vulns, for whatever the reason, then having a WAF as an available option is very nice.

      Anyway, my question back to you is… when you say, “appropriate security testing prior to deployment”… what do you mean by that exactly? I ask with context of what is “appropriate” for one project or company may not be for another.

  • conrad reynolds

    If the company or project is interested in producing a reliable product, they should go back and read Dr. Deming. Start with “Out of the Crisis”. It’s been proven to work.

    However, I will allow that producing a reliable product is not always the goal for a company or project. For those people, best practices simply don’t apply.

  • Shawn Sparks

    I think people tend to get carried away with thinking “best practices” apply in every context. I see best practices as those things which are most effective when considered “in general”, “without context”, or “in all contexts”. As a result, it is usually a good idea to expand upon a best practice by describing the contexts in which it excels and those in which it is not as beneficial. This lack of describing good/bad contexts is where “best practices” tend to fall short. Not because the best practice is not a best practice, but rather because it fails to be properly defined/described. It is easier to post a 5-point list to a blog than go into educated detail as Jeremiah Grossman did here; not to mention most of us do not want to read that much or have to really think about how to solve our problems.

  • Pingback: 32 of the Best and Worst Infosec Analogies | My Blog()

  • chris

    I was under the impression that best practices are to be used as a framework or guideline, not a bible. You adapt as much as possible to your organization–they’re not the be all end all. From what I understand, it seems like you’re lumping best practices and certifications/standards (ISO 9000,etc) into one.

  • http://www.testing-whiz.com/ Prashant Chambakara

    That’s really best practices you have mentioned for web application security. There are also certain other terms which can be considered for web app testing for security. I’ve shared my ideas on it, hope that might be useful for you either. Here’s the link http://www.softwaretestingtimes.com/2014/01/Website-Security-Testing-Concepts.html

  • Pingback: Marmaladebox | Information | Security | Management()