Chapter 1: Security today

Introduction

The introduction places security among software qualities that may be hard to see in a working application but need attention from the start of development.

• Functional and nonfunctional qualities: Distinguish an application's visible business functionality from nonfunctional qualities such as security, performance, scalability, and availability.
  Why it matters: A working feature does not, by itself, show whether the application is secure.
• Early attention to security: Explain why developers should consider security and other nonfunctional qualities early in development rather than judging an application only by whether its features work.
  Why it matters: Considering security early helps avoid risks that may stay unnoticed until they cause wider harm.

Key terms: functional aspects, nonfunctional software qualities, security, nonfunctional requirements, distributed denial of service [DDoS] attack

1.1 Discovering Spring Security

The section introduces Spring Security as a configurable way to build application-level security into Spring applications, while emphasizing that developers must choose and configure the protections their applications need.

• Spring Security’s place in Spring: Explain what Spring Security contributes to a Spring application and how its configuration fits the usual Spring style.
  Why it matters: This explains why Spring developers can add security without treating it as an entirely separate programming model.
• Developer responsibility for protection: Explain why adding Spring Security does not by itself make an application secure, and describe the developer’s role in choosing protections.
  Why it matters: A framework cannot protect a resource that the developer has failed to cover or has configured incorrectly.
• Request interception and permissions: Describe the application-level access decision illustrated in the section and the role of configured Spring Security components in it.
  Why it matters: It connects the general idea of application security to a concrete decision about access to actions and data.
• Stored data and communication protection: Describe the other protection responsibilities the section attributes to configured security components, without assuming they happen automatically.
  Why it matters: It shows that protecting an application may require attention to data storage and communication as well as access requests.
• Apache Shiro as an alternative: Distinguish the section’s broad comparison of Apache Shiro and Spring Security.
  Why it matters: The comparison makes clear that Spring Security is a strong choice for Spring applications, not the only conceivable security framework.

Key terms: Spring Security, application-level security, authentication, authorization, beans, annotations, configure, customize, functional requirements, architecture

1.2 What is software security?

Defines software and application-level security through sensitive data, layered defenses, access decisions, and risks to stored, transmitted, and in-memory information.

• Protection of sensitive data: Explain what counts as sensitive data and what an application must prevent others from doing with it.
  Why it matters: This establishes what the application’s security measures are meant to protect.
• Layered application security: Explain why security needs multiple layers and what application-level security contributes, using the example of one service impersonating another.
  Why it matters: A secure outer layer cannot replace checks within an application or between services.
• Authentication and authorization roles: Distinguish authentication from authorization and explain why sharing a user's credentials with a component can give it excessive access.
  Why it matters: Identifying a caller and limiting its privileges are different decisions, including when the caller is another component.
• Stored and transmitted data: Distinguish data at rest from data in transition and describe the protections the section identifies for stored data and secrets.
  Why it matters: Where data resides affects which risks and protections the application must consider.
• Sensitive data in memory: Describe how keeping sensitive data in an application's heap can create a vulnerability.
  Why it matters: Protecting stored data alone does not eliminate exposure of secrets while an application runs.

Key terms: sensitive data, security, security layers, application-level security, Spring Security, authentication, authorization, privileges, credentials, data at rest

1.3 Why is security important?

The section explains why applications must protect data and actions, how security failures harm users and organizations, and why early security investment is usually worth its cost.

• Protection Based on Sensitivity: Explain why an application must protect both data and actions to an appropriate degree, accounting for how much they matter to different people.
  Why it matters: Thinking about what users need protected helps you judge the consequences of unauthorized access.
• Costs of Security Failures: Describe how a small security weakness can harm users and organizations through unauthorized access or actions, lost trust, financial damage, and possible legal consequences.
  Why it matters: The damage from a weakness can continue even after a direct financial loss is repaid.
• Value of Early Investment: Justify investing time and resources in application security early by comparing prevention with the potential cost of an exploited vulnerability.
  Why it matters: Security work is easier to justify when you compare its cost with the likely consequences of a failure.

Key terms: data, actions, sensitivity, desired degree of access, vulnerability, trust, image, legal repercussions, investing early, security mechanisms

1.4 What will you learn in this book?

This section outlines the book’s practical approach, prerequisites, and topics it will cover.

1.5 Summary