Web- and cloud-based applications are being developed at a breakneck pace as technology advances more quickly than ever before. Companies that aren’t first to market often are left behind, but putting speed above security has led to a serious consequence: Many applications are fundamentally flawed, making it possible for hackers to steal critical data, hijack user inputs or deny service entirely. Better security isn’t impossible. The following slides present an application security checklist — a look at how your company can counter the impact of seven top application security threats.

Hackers will try to break in if your application lives on the Internet. Unfortunately, your code provides the easiest access to most applications. The problem is timid testing. Don’t take for granted that threat actors will overlook your apps because yours isn’t a high-profile enterprise application, and you aren’t connected to a critical database. Hackers are opportunists looking for the easiest way into ANY network — and the median number of app vulnerabilities has climbed from just six in 2013 to 20. While protecting applications from all malicious actors likely is impossible, you can significantly reduce the chance of a successful attack with comprehensive testing. Test everything. Data inputs. Data outputs. Give developers the time and resources to “break” their applications and see what happens. Hire third parties to claw their way in and cause trouble. When it comes to code, never take anything for granted.

Threat No. 1 | Timid Testing

Threat No. 2 | DoS and DDoS A Denial of Service (DoS) attacks are one of the quickest ways to sideline your application. Hackers can interrupt or disable access to the web- or cloud-based applications by flooding them with access requests or strings of random characters. Unfortunately, it gets worse: Many cybercriminals now use multiple infected machines — a “botnet” — to conduct what’s known as a distributed denial-of-service attack (DDoS). These attacks happen much faster, are harder to predict, and shut down sites or applications within minutes. More recent variants leveraged Internet of Things-connected devices such as cameras and routers to deliver DDoS speeds of up to a terabyte per second, more than any application or site can reasonably handle.

Threat No. 3 | DoS and DDoS (continued) To handle DoS and DDoS threats, first recognize you’re not alone: 53 percent of IT security pros said in a survey that DoS ranks among their top concerns. But there are tools you can add to do the following: Detect a sudden uptick in access requests. Shut down multiple requests from the same IP. Send alerts to administrators if potential DDoS activity is detected.

Threat No. 4 | SQL Injection Many apps now include “username” and “password” fields that use structured query language (SQL) to make a database request, typically using the “SELECT” query. But many apps don’t block the use of other SQL commands in these fields, making it possible for hackers to exploit common access points to gain total database control. Thanks to the rise of automated tools that can spam apps with SQL requests to see what works, this is especially problematic. At least one estimate says 60 percent of all web apps are vulnerable to SQL injection. 60% Vulnerable of all web apps are

Threat No. 5 | SQL Injection (continued) Solving the problem starts with cleaning up your app. First, it’s a good idea to include code strings that force the application to replace all single apostrophes with double apostrophes, making it impossible for hackers to use it as a string delimiter. Next, eliminate any debugging information pushed to the user in the event of an application error since this could give them valuable database knowledge—finally, lockdown account permissions tied to executable web app code.

Threat No. 6 | XSS Attacks It’s estimated that more than half of all web applications contain cross-site scripting (XSS) vulnerabilities. Attackers try to alter the function of an app by injecting a new “script” and forcing the application to execute it, in turn giving them control of a website or application and all content seen by users. While some programming languages come with controls, such as the “same-origin policy” to curtail the use of outside code, XSS attacks may be able to bypass this requirement. Cutting off cross-site scripting means adopting many key defensive strategies, such as developing a content security policy that determines which web-based scripts can and can’t be loaded by an app. It’s also good to employ input validation and output encoding to help mitigate this threat. Input validation ensures that data entry matches an expected format, while output encoding mandates that specific characters are treated as display text instead of executable code.

Threat No. 7 | Stock Permissions and APIs To make creating apps easier, many developers rely on application programming interfaces (APIs). Why re-create work that’s already been done by someone else? But there’s a problem: While enterprises are taking steps to control API use, 65 percent say they have no processes for overall API security. As a result, if hackers can find vulnerabilities in the APIs used to create your app, they may also have access to your code. The same goes for stock permissions — the “standard” username and password many developers build into their testing apps but never remove when the code goes live. As a result, hackers may easily breach your app with just a bit of brute-force effort. Best practices to fight this:

• Use more encryption than you think is necessary.
• Build-in code delays. Examples of code delays would be email verifications or increasing periods between each unsuccessful login attempt. This would deter hackers who use automated bots for fishing for username and password combinations. 65%no process for overall API security

Threat No. 8 | Hijacking Sessions To ensure users enjoy an optimal app experience, many developers build in a session ID, a unique identifier for individual application sessions. A new ID is generated for each subsequent visit, so data from a previous session can’t be used to corrupt a current connection. The problem is that hackers able to intrude on a session in progress may also hijack session IDs (often stored in “cookies”) and take user-end control. There may be no foolproof way to prevent this. It’s recommended that you do not turn off “cookies” since this lowers overall security. Ideally, you want session IDs that are randomly generated and encrypted to be paired with an application that can detect hacking attempts.

Threat No. 9 | Zero-Day Attacks occur when your app hits the ground running, and attackers immediately exploit a flaw overlooked during testing. Given the sheer number of apps in development and the amount of code reused from application to application, it’s no surprise hackers can often predict some of the common code developers use to empower popular web app functions. Ways to limit the impact of zero-day efforts include:

• Produce in-house code not publicly available from open-source developers.
• Build-in specific security measures that hackers won’t be expecting.
• Pull the app, do a deep dive, and fix the problem if the vulnerability is severe enough.