**## Web Security

As mentioned in this article: "According to numerous studies, the preferred method for attacking business' online assets is via their Web Applications."

The worst part: A recent report found that 86 percent of web applications tested had serious issues with authentication, access control, and confidentiality. Even worse still, 52% of web applications suffered from commonly-known vulnerabilities, like Cross-Site Scripting, SQL Injection, and others.

Consider that for a moment: Most business web applications suffer from widely known, yet preventable security vulnerabilities. We’re not even talking about new threats. These are vulnerabilities listed as a top security threat for over 10 years running.

Why does this happen? While the reasons vary, one issue is that many developers still take a cavalier approach to security. They treat it like a feature they can just add at the end. The fact is, that’s not how modern web application security works. More than ever, security must be built into your web applications from the very start.

“For us, the first and most important principle is security,” says Ryan Riley, Partner at Something Creative. “Nothing has evolved and changed more online than cyber security. We can discuss the principles of design and how people explore web pages. We can discuss best practices for building a framework. But none of it matters if your app or site is not secure. We live in a world where customer data is stolen by hackers daily. So for us we make sure that our authentication mechanisms are in place from the beginning and that data is secure during transit.”

The best security practices should be part of the development life cycle. According to the latest 2013 OWASP threat assessment, following are the top 10 in the order of priority.

• Injection
• Broken Authentication and Session Management
• Cross-Site Scripting (XSS)
• Insecure Direct Object References
• Security Misconfiguration
• Sensitive Data Exposure
• Missing Function Level Access Control
• Cross-Site Request Forgery (CSRF)
• Using Known Vulnerable Components
• Invalidated Redirects and Forwards

Same-origin Policy

Regular web pages can use the XMLHttpRequest object to send and receive data from remote servers, however they’re restricted in what they can do by the same origin-policy. This is an important concept in the browser security model and dictates that a web browser may only allow scripts on page A to access data on page B if these two pages have the same origin. The origin of a page is defined by its protocol, host and port number. For example the origin of this page is ‘https’, ‘www.sitepoint.com’, ’80’.

The same-origin policy is a saftey mechanism. It prevents scripts from reading data from your domain and sending it to their servers. If we didn’t have this, it would be easy for a malicious website to grab your session information to another site (such as Gmail or Twitter) and execute actions on your behalf. The same-origin policy is a saftey mechanism. It prevents scripts from reading data from your domain and sending it to their servers. If we didn’t have this, it would be easy for a malicious website to grab your session information to another site (such as Gmail or Twitter) and execute actions on your behalf.

JSONP

JSONP (which stands for JSON with Padding) builds on this technique and provides us with a way to access the returned data. It does this by having the server return JSON data wrapped in a function call (the “padding”) which can then be interpreted by the browser. This function must be defined in the page evaluating the JSONP response

jsonCallback(
  {
    "sites":
    [
      {
        "siteName": "SitePoint",
        "domainName": "https://www.sitepoint.com",
        "description": "SitePoint is a hub for web developers to share their passion for building incredible Internet things."
      },
      {
        "siteName": "A List Apart",
        "domainName": "http://alistapart.com/",
        "description": "A List Apart explores the design, development, and meaning of web content, with a special focus on web standards and best practices."
      },
      {
        "siteName": "Smashing Magazine",
        "domainName": "https://www.smashingmagazine.com/",
        "description": "Smashing Magazine delivers useful and innovative information to Web designers and developers."
      }
    ]
  }
);

CORS

Cross-Origin Resource Sharing (CORS) is a W3C spec to allow cross-domain communication from the browser. This is done by including a new Access-Control-Allow-Origin HTTP header in the response.

With reference to our first example, you could add the following to a .htaccess file (assumes Apache) to permit requests from a different origins:

Header add Access-Control-Allow-Origin "http://my-domain.com"

When making cross-origin requests, the destination website has to be the one who has your origin enabled and allows you to read the response from the request.