This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Guide Introduction"
Weilin Zhong (talk | contribs) |
(→Developing Secure Applications) |
||
| (22 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | [[Guide Table of Contents| Development Guide Table of Contents]] | |
| + | __TOC__ | ||
| + | |||
| + | Welcome to the Development OWASP Guide 3.0! | ||
| − | |||
Web application security is an essential component of any successful project, whether open source PHP applications, web services such as straight through processing, or proprietary business web sites. Hosters (rightly) shun insecure code, and users shun insecure services that lead to fraud. | Web application security is an essential component of any successful project, whether open source PHP applications, web services such as straight through processing, or proprietary business web sites. Hosters (rightly) shun insecure code, and users shun insecure services that lead to fraud. | ||
| − | The aim of this Guide is to allow businesses, developers, designers and solution architects to produce secure web applications. If done from the earliest stages, secure applications cost about the same to develop as insecure applications, but are far more cost effective in the long run. | + | |
| + | The aim of this Development Guide is to allow businesses, developers, designers and solution architects to produce secure web applications. If done from the earliest stages, secure applications cost about the same to develop as insecure applications, but are far more cost effective in the long run. | ||
==Developing Secure Applications == | ==Developing Secure Applications == | ||
| − | Unlike other forms of security (such as firewalls and secure lockdowns), web applications have the ability to make a skilled attacker rich, or make the life of a victim a complete misery. At this highest level of the OSI software map, traditional firewalls | + | |
| − | The Guide has been written to cover all forms of web application security issues, from old hoary chestnuts such as SQL | + | Unlike other forms of security (such as firewalls and secure lockdowns), web applications have the ability to make a skilled attacker rich, or make the life of a victim a complete misery. At this highest level of the OSI software map, traditional firewalls and other controls simply do not help. The application itself must be self-defending. The Development Guide can help you get there. |
| + | |||
| + | The Development Guide has been written to cover all forms of web application security issues, from old hoary chestnuts such as SQL Injection, through modern concerns such as AJAX, phishing, credit card handling, session fixation, cross-site request forgeries, compliance, and privacy issues. | ||
| + | |||
==Improvements in this edition == | ==Improvements in this edition == | ||
| − | This latest edition of the Guide builds upon the successful release of the Guide 2.0 at BlackHat Las Vegas in July 2005. With fearless editing by our publisher, No Starch Press, this edition aims to be concise and accurate. There are three new chapters, and a great deal of new content throughout. | + | |
| + | This latest edition of the Development Guide builds upon the successful release of the Development Guide 2.0 at BlackHat Las Vegas in July 2005. With fearless editing by our publisher, No Starch Press, this edition aims to be concise and accurate. There are three new chapters, and a great deal of new content throughout. | ||
| + | |||
Each chapter is organized into roughly three sections: | Each chapter is organized into roughly three sections: | ||
| + | |||
* Best practices – Practices or features every application should possess | * Best practices – Practices or features every application should possess | ||
* Secure patterns – Optional secure patterns, such as the best way to do password self-help | * Secure patterns – Optional secure patterns, such as the best way to do password self-help | ||
* Anti-patterns – if you have these in your code, you are more insecure | * Anti-patterns – if you have these in your code, you are more insecure | ||
| + | |||
==How to use this Guide == | ==How to use this Guide == | ||
| − | This Guide is a large work as it aims for completeness. The best way to treat the Guide is as a dictionary of best practices. However, web application security is like a language – without some form of context – it is nearly impossible to speak it well. Therefore, readers are well advised to read the “Security Principles” chapter in its entirety. | + | |
| + | This Development Guide is a large work as it aims for completeness. The best way to treat the Development Guide is as a dictionary of best practices. However, web application security is like a language – without some form of context – it is nearly impossible to speak it well. Therefore, readers are well advised to read the “Security Principles” chapter in its entirety. | ||
| + | |||
==Updates and errata == | ==Updates and errata == | ||
| − | The Guide will likely have errors and deficiencies. We will publish errata on our web site from time to time if you’d like to keep your copy up to date. | + | |
| − | If you have any comments or suggestions on the Guide, please e-mail the Guide mail list (see our web site for details) or contact me directly. | + | The Development Guide will likely have errors and deficiencies. We will publish errata on our web site from time to time if you’d like to keep your copy up to date. |
| + | |||
| + | If you have any comments or suggestions on the Development Guide, please e-mail the Development Guide mail list (see our web site for details) or contact me directly. | ||
| + | |||
==With thanks == | ==With thanks == | ||
| − | I wish to extend my thanks to the many authors, reviewers, and editors for their hard work in producing this | + | |
| + | I wish to extend my thanks to the many authors, reviewers, and editors for their hard work in producing this Development Guide. We stand on the shoulders of giants, and this Development Guide is no exception. | ||
| + | |||
Lastly, I wish to thank No Starch Press, particularly our editors and Bill Pollock for believing in us, and bringing our community’s text into a publishable state. | Lastly, I wish to thank No Starch Press, particularly our editors and Bill Pollock for believing in us, and bringing our community’s text into a publishable state. | ||
| + | |||
Andrew van der Stock, [email protected] | Andrew van der Stock, [email protected] | ||
Melbourne, Australia | Melbourne, Australia | ||
| Line 27: | Line 45: | ||
| − | + | [[Guide Table of Contents|Development Guide Table of Contents]] | |
| − | |||
| − | |||
| − | [[Guide Table of Contents]] | ||
[[Category:OWASP_Guide_Project]] | [[Category:OWASP_Guide_Project]] | ||
Latest revision as of 14:14, 1 March 2009
Development Guide Table of Contents
Welcome to the Development OWASP Guide 3.0!
Web application security is an essential component of any successful project, whether open source PHP applications, web services such as straight through processing, or proprietary business web sites. Hosters (rightly) shun insecure code, and users shun insecure services that lead to fraud.
The aim of this Development Guide is to allow businesses, developers, designers and solution architects to produce secure web applications. If done from the earliest stages, secure applications cost about the same to develop as insecure applications, but are far more cost effective in the long run.
Developing Secure Applications
Unlike other forms of security (such as firewalls and secure lockdowns), web applications have the ability to make a skilled attacker rich, or make the life of a victim a complete misery. At this highest level of the OSI software map, traditional firewalls and other controls simply do not help. The application itself must be self-defending. The Development Guide can help you get there.
The Development Guide has been written to cover all forms of web application security issues, from old hoary chestnuts such as SQL Injection, through modern concerns such as AJAX, phishing, credit card handling, session fixation, cross-site request forgeries, compliance, and privacy issues.
Improvements in this edition
This latest edition of the Development Guide builds upon the successful release of the Development Guide 2.0 at BlackHat Las Vegas in July 2005. With fearless editing by our publisher, No Starch Press, this edition aims to be concise and accurate. There are three new chapters, and a great deal of new content throughout.
Each chapter is organized into roughly three sections:
- Best practices – Practices or features every application should possess
- Secure patterns – Optional secure patterns, such as the best way to do password self-help
- Anti-patterns – if you have these in your code, you are more insecure
How to use this Guide
This Development Guide is a large work as it aims for completeness. The best way to treat the Development Guide is as a dictionary of best practices. However, web application security is like a language – without some form of context – it is nearly impossible to speak it well. Therefore, readers are well advised to read the “Security Principles” chapter in its entirety.
Updates and errata
The Development Guide will likely have errors and deficiencies. We will publish errata on our web site from time to time if you’d like to keep your copy up to date.
If you have any comments or suggestions on the Development Guide, please e-mail the Development Guide mail list (see our web site for details) or contact me directly.
With thanks
I wish to extend my thanks to the many authors, reviewers, and editors for their hard work in producing this Development Guide. We stand on the shoulders of giants, and this Development Guide is no exception.
Lastly, I wish to thank No Starch Press, particularly our editors and Bill Pollock for believing in us, and bringing our community’s text into a publishable state.
Andrew van der Stock, [email protected] Melbourne, Australia December, 2005
