Coders Conquer Security: Share & Learn Series - Information Exposure
"Loose lips sink ships" was a phrase which became popular in the United States during World War II. In Britain, you heard "Careless talk costs lives." The main point of the saying was that careless speaking about sensitive information could be overheard by spies and lead to serious consequences.
The same principle holds true when building web applications. When your web app reveals too much information, it can make it easier for attackers to break into it.
In this post, we'll cover what information exposure is, why it's dangerous, and how to prevent it.
Understand Information Exposure
Information exposure refers to web applications which expose internal information to those who shouldn't see it. It can also refer to exposing sensitive customer information through log files or the user interface. Either way, attackers can use the information they find to attack your systems or your users.
Often, the first step for an attacker is to try to create an error within your application. Poor error handling and web application configuration leads to information exposure with error messages. What happens if the attacker creates an error within your application? If a technical error message appears, including technical details such as a stack trace, you've revealed too much information. These details can include what database you're using or what version of the application server you're running.
Sensitive information disclosure can occur in other ways. Are there hidden fields on a form that hold sensitive information? Attackers can simply view the source of the page and see the values.
In a nutshell, information exposure occurs when information which should be on a need-to-know basis with your users is made too easily accessible.
Understand Why Information Exposure is Dangerous
What can an attacker do with information exposed by the application? If the information is sensitive in nature, an attacker could steal identities or user credentials. This could lead to financial damages, privacy violations, and regulatory fines
If an attacker uses error messages to gain information about an application, that information could be used in a future attack. In fact, the OWASP Testing Guide has an entire section about information gathering.
The OWASP Testing Guide encourages the use of search engines to find out information about your website you may not intend. For example, are your administrative pages exposed to search engines? Use the robots.txt file to tell search engines not to index certain pages. At the same time, the robots.txt file can leak information as well. Sensitive URLs can at times reside on the robots.txt file. The attackers pull the file down and start learning some of the directory structure of the site.
Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>
HTTP headers, website banners, and even comments within HTML and JavaScript code could have information attackers shouldn't see. HTTP headers can reveal application servers and version numbers. Attackers can use this information to find exploits to use against those specific versions. Make sure you understand all of the different places attackers could find your information and how to hide it appropriately.
Defeat Information Exposure
Information disclosure is often a problem with web application configuration. Many application servers return stack traces in error messages by default. Make sure to change this setting for production applications to redirect to a generic error page while logging the error for troubleshooting purposes. Detailed error messages should never be returned to the user's browser.
If you have any files necessary for the application which contain sensitive information, make sure proper access control ensures that only the application itself can read it. Disable directory listing on the server and move these files outside of the web root directory. This prevents attackers from navigating to the file using the browser using a directory traversal attack.
Logs can be used to gather information when not configured correctly. When an error occurs, don't log sensitive information such as passwords, session tokens, or personally identifiable information (PII). If an attacker could gain access to log files, they would find a treasure trove of sensitive information to steal. Don't log more than is necessary, which is usually an account identifier, a detailed error message, and maybe the method the error occurred in or the operation being performed. Assume log files aren't secret and you won't be tempted to place sensitive information within them.
Don't Sink Your Web Apps
Could you really have leaked information while speaking to a friend, directly leading to a battleship being lost in World War II? Maybe not. But why run the risk? That's the lesson of the saying, "Loose lips sink ships."
Similarly, there's no reason to expose the internal workings of your web application to the outside world. There's no reason to view entire credit card numbers or passwords. There's no reason to have PII data in log files. So don't do it. Check out our learning resources to learn more about information exposure.
Keep the internal workings of your applications where they belong. Don't sink your web apps.
Do you think you can put a stop to information exposure right now? Step up to the challenge, warrior: [Start Here]
When your web app reveals too much information, it can make it easier for attackers to break into it. jIn this post, we'll cover what information exposure is, why it's dangerous, and how to prevent it.
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
"Loose lips sink ships" was a phrase which became popular in the United States during World War II. In Britain, you heard "Careless talk costs lives." The main point of the saying was that careless speaking about sensitive information could be overheard by spies and lead to serious consequences.
The same principle holds true when building web applications. When your web app reveals too much information, it can make it easier for attackers to break into it.
In this post, we'll cover what information exposure is, why it's dangerous, and how to prevent it.
Understand Information Exposure
Information exposure refers to web applications which expose internal information to those who shouldn't see it. It can also refer to exposing sensitive customer information through log files or the user interface. Either way, attackers can use the information they find to attack your systems or your users.
Often, the first step for an attacker is to try to create an error within your application. Poor error handling and web application configuration leads to information exposure with error messages. What happens if the attacker creates an error within your application? If a technical error message appears, including technical details such as a stack trace, you've revealed too much information. These details can include what database you're using or what version of the application server you're running.
Sensitive information disclosure can occur in other ways. Are there hidden fields on a form that hold sensitive information? Attackers can simply view the source of the page and see the values.
In a nutshell, information exposure occurs when information which should be on a need-to-know basis with your users is made too easily accessible.
Understand Why Information Exposure is Dangerous
What can an attacker do with information exposed by the application? If the information is sensitive in nature, an attacker could steal identities or user credentials. This could lead to financial damages, privacy violations, and regulatory fines
If an attacker uses error messages to gain information about an application, that information could be used in a future attack. In fact, the OWASP Testing Guide has an entire section about information gathering.
The OWASP Testing Guide encourages the use of search engines to find out information about your website you may not intend. For example, are your administrative pages exposed to search engines? Use the robots.txt file to tell search engines not to index certain pages. At the same time, the robots.txt file can leak information as well. Sensitive URLs can at times reside on the robots.txt file. The attackers pull the file down and start learning some of the directory structure of the site.
Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>
HTTP headers, website banners, and even comments within HTML and JavaScript code could have information attackers shouldn't see. HTTP headers can reveal application servers and version numbers. Attackers can use this information to find exploits to use against those specific versions. Make sure you understand all of the different places attackers could find your information and how to hide it appropriately.
Defeat Information Exposure
Information disclosure is often a problem with web application configuration. Many application servers return stack traces in error messages by default. Make sure to change this setting for production applications to redirect to a generic error page while logging the error for troubleshooting purposes. Detailed error messages should never be returned to the user's browser.
If you have any files necessary for the application which contain sensitive information, make sure proper access control ensures that only the application itself can read it. Disable directory listing on the server and move these files outside of the web root directory. This prevents attackers from navigating to the file using the browser using a directory traversal attack.
Logs can be used to gather information when not configured correctly. When an error occurs, don't log sensitive information such as passwords, session tokens, or personally identifiable information (PII). If an attacker could gain access to log files, they would find a treasure trove of sensitive information to steal. Don't log more than is necessary, which is usually an account identifier, a detailed error message, and maybe the method the error occurred in or the operation being performed. Assume log files aren't secret and you won't be tempted to place sensitive information within them.
Don't Sink Your Web Apps
Could you really have leaked information while speaking to a friend, directly leading to a battleship being lost in World War II? Maybe not. But why run the risk? That's the lesson of the saying, "Loose lips sink ships."
Similarly, there's no reason to expose the internal workings of your web application to the outside world. There's no reason to view entire credit card numbers or passwords. There's no reason to have PII data in log files. So don't do it. Check out our learning resources to learn more about information exposure.
Keep the internal workings of your applications where they belong. Don't sink your web apps.
Do you think you can put a stop to information exposure right now? Step up to the challenge, warrior: [Start Here]
"Loose lips sink ships" was a phrase which became popular in the United States during World War II. In Britain, you heard "Careless talk costs lives." The main point of the saying was that careless speaking about sensitive information could be overheard by spies and lead to serious consequences.
The same principle holds true when building web applications. When your web app reveals too much information, it can make it easier for attackers to break into it.
In this post, we'll cover what information exposure is, why it's dangerous, and how to prevent it.
Understand Information Exposure
Information exposure refers to web applications which expose internal information to those who shouldn't see it. It can also refer to exposing sensitive customer information through log files or the user interface. Either way, attackers can use the information they find to attack your systems or your users.
Often, the first step for an attacker is to try to create an error within your application. Poor error handling and web application configuration leads to information exposure with error messages. What happens if the attacker creates an error within your application? If a technical error message appears, including technical details such as a stack trace, you've revealed too much information. These details can include what database you're using or what version of the application server you're running.
Sensitive information disclosure can occur in other ways. Are there hidden fields on a form that hold sensitive information? Attackers can simply view the source of the page and see the values.
In a nutshell, information exposure occurs when information which should be on a need-to-know basis with your users is made too easily accessible.
Understand Why Information Exposure is Dangerous
What can an attacker do with information exposed by the application? If the information is sensitive in nature, an attacker could steal identities or user credentials. This could lead to financial damages, privacy violations, and regulatory fines
If an attacker uses error messages to gain information about an application, that information could be used in a future attack. In fact, the OWASP Testing Guide has an entire section about information gathering.
The OWASP Testing Guide encourages the use of search engines to find out information about your website you may not intend. For example, are your administrative pages exposed to search engines? Use the robots.txt file to tell search engines not to index certain pages. At the same time, the robots.txt file can leak information as well. Sensitive URLs can at times reside on the robots.txt file. The attackers pull the file down and start learning some of the directory structure of the site.
Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>
HTTP headers, website banners, and even comments within HTML and JavaScript code could have information attackers shouldn't see. HTTP headers can reveal application servers and version numbers. Attackers can use this information to find exploits to use against those specific versions. Make sure you understand all of the different places attackers could find your information and how to hide it appropriately.
Defeat Information Exposure
Information disclosure is often a problem with web application configuration. Many application servers return stack traces in error messages by default. Make sure to change this setting for production applications to redirect to a generic error page while logging the error for troubleshooting purposes. Detailed error messages should never be returned to the user's browser.
If you have any files necessary for the application which contain sensitive information, make sure proper access control ensures that only the application itself can read it. Disable directory listing on the server and move these files outside of the web root directory. This prevents attackers from navigating to the file using the browser using a directory traversal attack.
Logs can be used to gather information when not configured correctly. When an error occurs, don't log sensitive information such as passwords, session tokens, or personally identifiable information (PII). If an attacker could gain access to log files, they would find a treasure trove of sensitive information to steal. Don't log more than is necessary, which is usually an account identifier, a detailed error message, and maybe the method the error occurred in or the operation being performed. Assume log files aren't secret and you won't be tempted to place sensitive information within them.
Don't Sink Your Web Apps
Could you really have leaked information while speaking to a friend, directly leading to a battleship being lost in World War II? Maybe not. But why run the risk? That's the lesson of the saying, "Loose lips sink ships."
Similarly, there's no reason to expose the internal workings of your web application to the outside world. There's no reason to view entire credit card numbers or passwords. There's no reason to have PII data in log files. So don't do it. Check out our learning resources to learn more about information exposure.
Keep the internal workings of your applications where they belong. Don't sink your web apps.
Do you think you can put a stop to information exposure right now? Step up to the challenge, warrior: [Start Here]
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
"Loose lips sink ships" was a phrase which became popular in the United States during World War II. In Britain, you heard "Careless talk costs lives." The main point of the saying was that careless speaking about sensitive information could be overheard by spies and lead to serious consequences.
The same principle holds true when building web applications. When your web app reveals too much information, it can make it easier for attackers to break into it.
In this post, we'll cover what information exposure is, why it's dangerous, and how to prevent it.
Understand Information Exposure
Information exposure refers to web applications which expose internal information to those who shouldn't see it. It can also refer to exposing sensitive customer information through log files or the user interface. Either way, attackers can use the information they find to attack your systems or your users.
Often, the first step for an attacker is to try to create an error within your application. Poor error handling and web application configuration leads to information exposure with error messages. What happens if the attacker creates an error within your application? If a technical error message appears, including technical details such as a stack trace, you've revealed too much information. These details can include what database you're using or what version of the application server you're running.
Sensitive information disclosure can occur in other ways. Are there hidden fields on a form that hold sensitive information? Attackers can simply view the source of the page and see the values.
In a nutshell, information exposure occurs when information which should be on a need-to-know basis with your users is made too easily accessible.
Understand Why Information Exposure is Dangerous
What can an attacker do with information exposed by the application? If the information is sensitive in nature, an attacker could steal identities or user credentials. This could lead to financial damages, privacy violations, and regulatory fines
If an attacker uses error messages to gain information about an application, that information could be used in a future attack. In fact, the OWASP Testing Guide has an entire section about information gathering.
The OWASP Testing Guide encourages the use of search engines to find out information about your website you may not intend. For example, are your administrative pages exposed to search engines? Use the robots.txt file to tell search engines not to index certain pages. At the same time, the robots.txt file can leak information as well. Sensitive URLs can at times reside on the robots.txt file. The attackers pull the file down and start learning some of the directory structure of the site.
Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>
HTTP headers, website banners, and even comments within HTML and JavaScript code could have information attackers shouldn't see. HTTP headers can reveal application servers and version numbers. Attackers can use this information to find exploits to use against those specific versions. Make sure you understand all of the different places attackers could find your information and how to hide it appropriately.
Defeat Information Exposure
Information disclosure is often a problem with web application configuration. Many application servers return stack traces in error messages by default. Make sure to change this setting for production applications to redirect to a generic error page while logging the error for troubleshooting purposes. Detailed error messages should never be returned to the user's browser.
If you have any files necessary for the application which contain sensitive information, make sure proper access control ensures that only the application itself can read it. Disable directory listing on the server and move these files outside of the web root directory. This prevents attackers from navigating to the file using the browser using a directory traversal attack.
Logs can be used to gather information when not configured correctly. When an error occurs, don't log sensitive information such as passwords, session tokens, or personally identifiable information (PII). If an attacker could gain access to log files, they would find a treasure trove of sensitive information to steal. Don't log more than is necessary, which is usually an account identifier, a detailed error message, and maybe the method the error occurred in or the operation being performed. Assume log files aren't secret and you won't be tempted to place sensitive information within them.
Don't Sink Your Web Apps
Could you really have leaked information while speaking to a friend, directly leading to a battleship being lost in World War II? Maybe not. But why run the risk? That's the lesson of the saying, "Loose lips sink ships."
Similarly, there's no reason to expose the internal workings of your web application to the outside world. There's no reason to view entire credit card numbers or passwords. There's no reason to have PII data in log files. So don't do it. Check out our learning resources to learn more about information exposure.
Keep the internal workings of your applications where they belong. Don't sink your web apps.
Do you think you can put a stop to information exposure right now? Step up to the challenge, warrior: [Start Here]
Table of contents
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Resources to get you started
10 Key Predictions: Secure Code Warrior on AI & Secure-by-Design’s Influence in 2025
Organizations are facing tough decisions on AI usage to support long-term productivity, sustainability, and security ROI. It’s become clear to us over the last few years that AI will never fully replace the role of the developer. From AI + developer partnerships to the increasing pressures (and confusion) around Secure-by-Design expectations, let’s take a closer look at what we can expect over the next year.
OWASP Top 10 For LLM Applications: What’s New, Changed, and How to Stay Secure
Stay ahead in securing LLM applications with the latest OWASP Top 10 updates. Discover what's new, what’s changed, and how Secure Code Warrior equips you with up-to-date learning resources to mitigate risks in Generative AI.
Trust Score Reveals the Value of Secure-by-Design Upskilling Initiatives
Our research has shown that secure code training works. Trust Score, using an algorithm drawing on more than 20 million learning data points from work by more than 250,000 learners at over 600 organizations, reveals its effectiveness in driving down vulnerabilities and how to make the initiative even more effective.
.png)
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
