5 Best Practices for Mashups

Andres Ferrate
Sep. 11 2008, 02:54AM EDT

A wide array of content and functionality has been incorporated into the ever-growing number of mashups out on the web today. From enterprise mashups to proof-of-concept hacks, developers and would be developers are leveraging the power of mashups to provide information in new and compelling ways.

Mashups are still a relatively new phenomena, and as this new type of online application evolves it will become increasingly more important to ensure that your mashup adheres to a variety of best practices. Summarized below are five key best practices that you should strive to use in the development of your mashup.


Perhaps the most important yet often overlooked part of a mashup is security. Mashups are inherently Web 2.0, which means that your mashup will likely rely on AJAX. AJAX is a great set of web development techniques, but it also poses a avriety of risks for end-users, including cross-site scripting (XSS), Cross-Site Request Forgeries (CSRF) and JSON Hijacking, and more. The Open AJAX Alliance has a great white paper on AJAX and Mashup Security that outlines specific security risks and best practices to address these risks. IBM and AJAXWorld have additional information on AJAX security as well.

In addition to securing mashups against AJAX vulnerabilities, end-user information also presents another security risk. A good number of social networking and social media sites provide APIs that allow third parties to access information for a specific user or users.

Consequently, there is a risk that a mashup may expose user credentials (including passwords, emails, etc.). The best way to avoid this scenario is to use open web standards such as OAuth or OpenID for user authentication/authorization. Regardless of whether either of these standards is used (or the site that provides the API supports them), a mashup should be designed to minimize the exposure of user information as much as possible. The Open Web Application Security Project (OWASP) has a wiki that includes a Guide to Authorization, and Niall Kennedy provides a good primer on the subject as well.


Mashups are applications, but they are also web sites. Depending on the target audience, a mashup may have reach across various types of users, who utilize different browsers and operating systems. An enterprise mashup developed in-house for a specific browser and operating system used throughout an organization will be less likely to require application logic to address differences in browsers (and differences within the same browser on different operating systems). However, a mashup developed for public consumption is likely to be used by a diverse base of end users, each with browsers that may require server-side and/or client-side modifications to your mashup code.

Whether it be CSS, JavaScript, HTML, or server-side scripting, chances are that modifications may need to be made to accommodate how a browser renders and interacts with a mashup. Apple's Developer Center summary on web page development best practices provides some good guidance that is relevant for mashup developers.


As with compatibility, a mashup's client-side and server-side performance can greatly affect an end user's experience. On the server-side, site performance can be compromised under high loads related to complex database queries, high user loads, or memory-intensive server-side scripting. Invest time in optimizing queries and code, and balancing user load.

Additionally, a mashup may load more slowly on certain browsers, depending on the content type and whether there is any JavaScript code being processed. A great example of this is seeing a browser freeze when trying to load a large number of map markers using the Google Maps API. Gear mashups towards limiting memory-intensive processes in the browser, and break up data/information into smaller sets using strategies such as paging.


As evidenced by our API Directory, there is an immense amount of content that is accessible via APIs. Each API typically carries terms of use that specify who can use content, how the content can be used, and how the content should be attributed. There are several attribution licenses out there, including Creative Commons and the GNU Free Documentation License.

Developers should be aware of the terms of attribution for any content, and adhere to the attribution method specified by those terms. Note also that some API methods include query parameters that can be used to specify what type of content should be retrieved (e.g., Creative Commons Share Alike vs. privately copyrighted).


In addition to attribution, developers should be aware of the terms of use for APIs used for mashups. Some APIs, such as the Google Maps API, have terms of use that explicitly state that the API can only be used for "services that are generally accessible to consumers without charge." Other APIs, such as Yelp's API, have terms of use that prohibit use of "the Yelp API or any Yelp Content in a manner that is directly competitive in nature with the Yelp Site". Be aware of how an API's terms of use will affect development and accessibility of a mashup, and consider the potential legal consequences of violating a provider's terms of use.

A mashup should also take into account other legal considerations, including copyright violations (just because its accessible via an API doesn't mean that the content may not be infringing upong copyrights), content for mature audiences, and accuracy of information; be sure to use relevant disclaimers and site policies to address these legal considerations.

There are certainly other best practices that are emerging in this space. Do you have additional thoughts on these best practices or additional ideas for mashup do's and don'ts? Please share them in the comments section below.

Andres Ferrate




I would add to oWasp's "Principle of least privilege" with "Principle of least locality".

With location awareness about to boil over, it is important to let the user define/expose what level of granularity apps read and publish. We must also allow for the user to temporarily turn location off without overwriting the established setting AND permit the user to wipe their recorded location points clean. See Fire Eagle user settings et al.

P.S. I find some mild irony that a post about "Best Practices" mentioning OpenID is appearing on a blog that does not support OpenID! WTF?