Xavfsizlik

Security ichiga quyidagilar kiradi: OAuth 2.0, OpenID Connect, JWT internals, Spring Security OAuth Resource Server, OWASP Top 10, Secrets management, Cryptography — JCA/JCE.

1. Security nima?

Security — ilovani, foydalanuvchi ma’lumotlarini, API’larni, tokenlarni, parollarni va biznes jarayonlarni himoya qilish.

Backend security faqat login-parol emas. Senior Java developer quyidagilarni tushunishi kerak:

Authentication
Authorization
Token security
Password hashing
API protection
Input validation
SQL injection
XSS
CSRF
Secrets management
Encryption
Transport security
Audit logging
Rate limiting

Oddiy qilib:

Security — “kim kirdi?”, “nima qila oladi?”, “ma’lumot xavfsizmi?”, “tizimni aldab bo‘ladimi?” degan savollarga javob.

2. Authentication va Authorization farqi

Bu juda muhim farq.

Authentication

Authentication — foydalanuvchi kimligini aniqlash.

Savol:

Siz kimsiz?

Misol:

Login: ali
Password: ****

Agar login va parol to‘g‘ri bo‘lsa, tizim biladi:

Bu Ali.

Authorization

Authorization — foydalanuvchining nima qilishga ruxsati borligini tekshirish.

Savol:

Siz buni qila olasizmi?

Masalan:

Ali oddiy user.
Ali admin panelga kira olmaydi.

Kodda:

@PreAuthorize("hasRole('ADMIN')")
@GetMapping("/admin/users")
public List<UserDto> getUsers() {
    return userService.getUsers();
}

Bu yerda foydalanuvchi login qilgan bo‘lsa ham, ADMIN bo‘lmasa kira olmaydi.

3. Session-based authentication

An’anaviy web ilovalarda session ishlatiladi.

Flow:

1. User login qiladi
2. Server session yaratadi
3. Browserga session cookie beradi
4. Keyingi requestlarda cookie yuboriladi
5. Server session orqali userni taniydi

Ko‘rinishi:

Browser → Cookie: JSESSIONID=abc123 → Server

Afzalliklari:

• web app uchun qulay;

• server sessionni nazorat qiladi;

• logout qilish oson;

• cookie HttpOnly bo‘lsa xavfsizroq.

Kamchiliklari:

• serverda session saqlanadi;

• horizontal scalingda session sharing kerak;

• mobile/API uchun har doim qulay emas.

4. Token-based authentication

REST API va microservice’da ko‘pincha token ishlatiladi.

Flow:

1. User login qiladi
2. Server access token beradi
3. Client tokenni saqlaydi
4. Har requestda Authorization header bilan yuboradi

Misol:

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Server tokenni tekshiradi va userni aniqlaydi.

5. OAuth 2.0

OAuth 2.0 — authorization framework.

U “foydalanuvchi nomidan boshqa ilovaga cheklangan ruxsat berish” uchun ishlatiladi.

Masalan:

Siz bir appga Google account orqali kirdingiz.
App sizning Google parolingizni bilmaydi.
Google appga token beradi.
App token orqali faqat ruxsat berilgan ma’lumotga kira oladi.

Muhim:

OAuth 2.0 authentication emas, authorization uchun yaratilgan.

Lekin real hayotda login flow’larda OpenID Connect bilan birga ishlatiladi.

5.1. OAuth 2.0 asosiy rollari

Misol:

User — Resource Owner
Mobile app — Client
Keycloak/Auth0/Google — Authorization Server
Backend API — Resource Server

5.2. OAuth 2.0 flow

Oddiy ko‘rinish:

User
 ↓
Client App
 ↓
Authorization Server
 ↓
Access Token
 ↓
Resource Server API

Client API’ga request qiladi:

GET /api/orders
Authorization: Bearer access_token

Resource Server tokenni tekshiradi.

6. OpenID Connect

OpenID Connect — OIDC OAuth 2.0 ustiga qurilgan authentication layer.

OAuth 2.0:

Ruxsat berish

OIDC:

User kimligini aniqlash

OIDC id_token tushunchasini olib keladi.

6.1. Access token vs ID token

Muhim qoida:

Backend API odatda access_tokenni tekshiradi. id_token API chaqirish uchun ishlatilmaydi.

7. JWT nima?

JWT — JSON Web Token. Token formatidir.

JWT uch qismdan iborat:

header.payload.signature

Masalan:

xxxxx.yyyyy.zzzzz

7.1. Header

Header token algoritmini bildiradi:

{
  "alg": "RS256",
  "typ": "JWT"
}

7.2. Payload

Payload ichida claimlar bo‘ladi:

{
  "sub": "123",
  "email": "ali@example.com",
  "roles": ["USER"],
  "iat": 1710000000,
  "exp": 1710003600
}

Muhim claimlar:

7.3. Signature

Signature tokenni o‘zgartirilmaganini tekshiradi.

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

Yoki RSA/ECDSA private key bilan imzolanadi.

Muhim:

JWT payload shifrlanmagan. U faqat Base64URL encoded. Ichiga parol, karta raqami, maxfiy data yozilmaydi.

8. JWT algoritmlari

HS256

Bitta secret bilan imzolanadi va tekshiriladi.

sign secret = verify secret

Mos:

• kichik tizimlar;

• bitta backend;

• ichki servis.

Xavfi:

• secret tarqalsa, token yaratish ham mumkin;

• microservice’da secretni ko‘p joyga tarqatish xavfli.

RS256

Private/public key ishlatiladi.

Private key → token imzolaydi
Public key → token tekshiradi

Mos:

• microservice;

• OAuth2/OIDC;

• Keycloak/Auth0;

• resource serverlar.

Afzalligi:

• API servislar faqat public key biladi;

• token yaratolmaydi, faqat tekshiradi;

• xavfsizroq arxitektura.

9. JWT bilan ko‘p qilinadigan xatolar

Xato 1: Token ichiga sensitive data yozish

Yomon:

{
  "userId": 1,
  "password": "123456",
  "cardNumber": "8600..."
}

To‘g‘ri:

{
  "sub": "1",
  "roles": ["USER"],
  "scope": "orders:read"
}

Xato 2: Token expiration qo‘ymaslik

Yomon:

{
  "sub": "1"
}

To‘g‘ri:

{
  "sub": "1",
  "exp": 1710003600
}

Access token qisqa yashashi kerak.

Masalan:

5–15 minut

Refresh token esa uzoqroq yashashi mumkin, lekin kuchli himoyalanishi kerak.

Xato 3: Signature tekshirmaslik

JWT decode qilish yetarli emas.

Yomon:

String payload = decodeJwt(token);

To‘g‘ri:

decode + verify signature + validate exp/iss/aud

Xato 4: alg: none zaifligi

Eski yoki noto‘g‘ri kutubxonalarda token algoritmini noto‘g‘ri qabul qilish xavfli bo‘lgan.

Senior qoida:

Qaysi algoritmga ruxsat borligini server tomonda aniq belgilash kerak.

10. Spring Security

Spring Boot’da security uchun asosiy framework — Spring Security.

U quyidagilarni beradi:

• authentication;

• authorization;

• filters;

• CSRF protection;

• password hashing;

• OAuth2 login;

• Resource Server;

• method security;

• security context.

11. Spring Security filter chain

Spring Security requestni filterlar orqali tekshiradi.

HTTP Request
 ↓
Security Filters
 ↓
Authentication
 ↓
Authorization
 ↓
Controller

Masalan:

BearerTokenAuthenticationFilter
UsernamePasswordAuthenticationFilter
AuthorizationFilter
ExceptionTranslationFilter

Senior developer filter chain tushunchasini bilishi kerak, chunki ko‘p security muammolar shu yerda chiqadi.

12. Spring Security 6 config

Hozirgi Spring Boot loyihalarda SecurityFilterChain ishlatiladi.

@Configuration
@EnableMethodSecurity
public class SecurityConfig {

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
                .csrf(csrf -> csrf.disable())
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers("/api/auth/**").permitAll()
                        .requestMatchers("/api/admin/**").hasRole("ADMIN")
                        .anyRequest().authenticated()
                )
                .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()))
                .build();
    }
}

Bu yerda:

.requestMatchers("/api/auth/**").permitAll()

login/register endpointlari ochiq.

.requestMatchers("/api/admin/**").hasRole("ADMIN")

admin endpoint faqat admin uchun.

.anyRequest().authenticated()

qolgan hamma endpointlar login talab qiladi.

13. OAuth2 Resource Server

Agar backend API access token qabul qilsa, u Resource Server bo‘ladi.

Masalan:

Frontend → Backend API
Authorization: Bearer JWT

Spring config:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: http://localhost:8080/realms/demo

Yoki public key/JWK set:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          jwk-set-uri: http://localhost:8080/realms/demo/protocol/openid-connect/certs

Spring tokenni:

• signature;

• expiration;

• issuer;

• format;

bo‘yicha tekshiradi.

14. Role va scope

OAuth2’da ko‘pincha scope ishlatiladi.

Masalan:

orders:read
orders:write
users:admin

Spring’da scope odatda authority sifatida keladi:

SCOPE_orders:read

Misol:

@PreAuthorize("hasAuthority('SCOPE_orders:read')")
@GetMapping("/orders")
public List<OrderDto> getOrders() {
    return orderService.getOrders();
}

Role esa:

@PreAuthorize("hasRole('ADMIN')")

E’tibor:

hasRole('ADMIN') → ROLE_ADMIN qidiradi
hasAuthority('ADMIN') → ADMIN qidiradi

Bu ko‘p chalkashadigan joy.

15. Password hashing

Parolni hech qachon plain text saqlash mumkin emas.

Yomon:

user.setPassword(request.password());

Yomonroq:

user.setPassword(Base64.encode(request.password()));

Base64 hashing emas, encryption ham emas.

To‘g‘ri:

@Bean
PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
}

Saqlash:

String hash = passwordEncoder.encode(request.password());
user.setPassword(hash);

Tekshirish:

passwordEncoder.matches(rawPassword, user.getPassword());

15.1. Nega BCrypt?

BCrypt:

• salt ishlatadi;

• sekin ishlaydi;

• brute force’ni qiyinlashtiradi;

• password hashing uchun mos.

Productionda Argon2 ham kuchli variant.

Spring’da:

@Bean
PasswordEncoder passwordEncoder() {
    return new Argon2PasswordEncoder(
            16,
            32,
            1,
            65536,
            3
    );
}

16. CSRF

CSRF — Cross-Site Request Forgery.

Bu browser cookie asosida authentication ishlatganda xavfli.

Scenario:

User bank.uz saytiga login qilgan
Cookie browserda bor
User zararli saytga kirdi
Zararli sayt bank.uz/payment endpointiga request yubordi
Browser cookie’ni avtomatik qo‘shib yubordi

Agar CSRF himoya bo‘lmasa, zararli request bajarilishi mumkin.

16.1. REST API’da CSRF kerakmi?

Agar siz:

Authorization: Bearer token

ishlatsangiz va tokenni cookie’da emas, headerda yuborsangiz, CSRF odatda kerak emas.

Shuning uchun ko‘p REST API’da:

.csrf(csrf -> csrf.disable())

ishlatiladi.

Lekin agar cookie-based auth bo‘lsa, CSRF’ni o‘chirib qo‘yish xavfli.

17. CORS

CORS — browser qaysi frontend domain API’ga request qila olishini belgilaydi.

Masalan:

frontend: https://app.example.com
backend: https://api.example.com

Agar CORS to‘g‘ri sozlanmasa, browser requestni bloklaydi.

Yomon:

@CrossOrigin("*")

Productionda xavfli.

Yaxshiroq:

@Bean
CorsConfigurationSource corsConfigurationSource() {
    CorsConfiguration config = new CorsConfiguration();
    config.setAllowedOrigins(List.of("https://app.example.com"));
    config.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE"));
    config.setAllowedHeaders(List.of("Authorization", "Content-Type"));
    config.setAllowCredentials(true);

    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/**", config);
    return source;
}

18. OWASP Top 10 Java context

OWASP Top 10 — web ilovalardagi eng muhim security xavflar ro‘yxati.

Senior Java developer bularni real kodda taniy olishi kerak.

18.1. Broken Access Control

User o‘ziga tegishli bo‘lmagan ma’lumotni ko‘ra olsa.

Yomon:

@GetMapping("/orders/{id}")
public OrderDto getOrder(@PathVariable Long id) {
    return orderService.getById(id);
}

Bu yerda user boshqa userning orderini ID orqali ko‘rishi mumkin.

To‘g‘ri:

@GetMapping("/orders/{id}")
public OrderDto getOrder(@PathVariable Long id,
                         Authentication authentication) {
    return orderService.getByIdForUser(id, authentication.getName());
}

Service ichida:

public OrderDto getByIdForUser(Long orderId, String username) {
    Order order = orderRepository.findByIdAndUsername(orderId, username)
            .orElseThrow(() -> new AccessDeniedException("Access denied"));

    return mapper.toDto(order);
}

18.2. Injection

SQL injection — user input SQL queryga noto‘g‘ri qo‘shilganda.

Yomon:

String sql = "SELECT * FROM users WHERE email = '" + email + "'";

Agar email:

'a' OR '1'='1

bo‘lsa, query buziladi.

To‘g‘ri:

@Query("select u from User u where u.email = :email")
Optional<User> findByEmail(@Param("email") String email);

Yoki JDBC:

PreparedStatement ps = connection.prepareStatement(
        "SELECT * FROM users WHERE email = ?"
);
ps.setString(1, email);

18.3. Cryptographic failures

Maxfiy ma’lumotlar noto‘g‘ri saqlansa yoki uzatilsa.

Xatolar:

• HTTP ishlatish;

• parolni plain text saqlash;

• zaif encryption algoritm;

• hardcoded secret;

• tokenni logga chiqarish.

Yomon:

log.info("JWT token: {}", token);

To‘g‘ri:

log.info("User authenticated: {}", userId);

18.4. Security misconfiguration

Noto‘g‘ri sozlamalar.

Misollar:

• default admin password;

• actuator endpointlar ochiq;

• stack trace productionda ko‘rinadi;

• CORS *;

• debug mode yoqilgan;

• H2 console productionda ochiq.

Spring Actuator uchun ehtiyot bo‘lish kerak:

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus

env, beans, heapdump, threaddump kabi endpointlarni ochiq qoldirish xavfli.

18.5. Vulnerable dependencies

Kutubxonalarda zaiflik bo‘lishi mumkin.

Masalan:

Eski log4j
Eski jackson
Eski spring-security
Eski netty

Amaliy himoya:

• dependency update;

• OWASP Dependency Check;

• Snyk;

• GitHub Dependabot;

• Trivy;

• Maven/Gradle audit.

Maven plugin misol:

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>12.1.0</version>
</plugin>

19. Secrets management

Secret — maxfiy qiymatlar.

Masalan:

DB password
JWT secret
API key
OAuth client secret
Private key
SMTP password
AWS access key
Telegram bot token

Yomon:

spring:
  datasource:
    password: mySuperPassword123

Yoki:

private static final String SECRET = "abc123";

Bu xavfli, chunki code repositoryga tushadi.

19.1. To‘g‘ri yondashuv

Secretlar quyida saqlanadi:

• environment variables;

• Kubernetes Secrets;

• HashiCorp Vault;

• AWS Secrets Manager;

• GCP Secret Manager;

• Azure Key Vault;

• Doppler/1Password Secrets Automation.

Spring Boot’da:

spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}

Environment:

export DB_PASSWORD='strong-password'

20. Encryption, hashing, encoding farqi

Bu uchalasi ko‘p aralashadi.

Encoding

hello → aGVsbG8=

Bu maxfiylik bermaydi.

Hashing

password → hash

Asl parolni qaytarib bo‘lmaydi.

Encryption

plain text → encrypted text → plain text

Key bo‘lsa qaytarish mumkin.

21. JCA/JCE

Java’da cryptography uchun asosiy API’lar:

JCA — Java Cryptography Architecture
JCE — Java Cryptography Extension

Ular quyidagilar uchun ishlatiladi:

• hashing;

• encryption/decryption;

• digital signature;

• key generation;

• certificate;

• secure random.

21.1. SHA-256 misol

public static String sha256(String input) throws Exception {
    MessageDigest digest = MessageDigest.getInstance("SHA-256");
    byte[] hash = digest.digest(input.getBytes(StandardCharsets.UTF_8));

    return HexFormat.of().formatHex(hash);
}

Lekin parol uchun oddiy SHA-256 yetarli emas.

Parol uchun:

BCrypt / Argon2 / PBKDF2

21.2. AES encryption misol

public class AesService {

    private static final String ALGORITHM = "AES/GCM/NoPadding";

    public byte[] encrypt(byte[] plainText, SecretKey key, byte[] iv) throws Exception {
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        GCMParameterSpec spec = new GCMParameterSpec(128, iv);

        cipher.init(Cipher.ENCRYPT_MODE, key, spec);

        return cipher.doFinal(plainText);
    }

    public byte[] decrypt(byte[] cipherText, SecretKey key, byte[] iv) throws Exception {
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        GCMParameterSpec spec = new GCMParameterSpec(128, iv);

        cipher.init(Cipher.DECRYPT_MODE, key, spec);

        return cipher.doFinal(cipherText);
    }
}

AES-GCM afzalligi:

• shifrlaydi;

• integrity ham tekshiradi;

• CBC’dan ko‘ra xavfsizroq ishlatish osonroq.

Muhim:

IV/nonce har encryption uchun unique bo‘lishi kerak. Keyni hardcode qilish mumkin emas.

22. API security checklist

Senior Java developer API uchun quyidagilarni tekshiradi:

Authentication bormi?
Authorization endpoint darajasida va object darajasida bormi?
JWT signature/exp/iss/aud tekshirilyaptimi?
Password BCrypt/Argon2 bilan hash qilinganmi?
Sensitive data logga chiqmayaptimi?
CORS production domainlarga cheklanganmi?
CSRF cookie auth ishlatilsa yoqilganmi?
Rate limiting bormi?
Input validation bormi?
SQL injectiondan himoya bormi?
Actuator endpointlar yopiqmi?
Secrets code ichida emasmi?
Dependency vulnerability scan bormi?
HTTPS majburiymi?
Audit log kerakli joylarda bormi?

23. Object-level authorization

Ko‘p tizimlarda endpointni himoya qilish yetarli emas.

Masalan:

@PreAuthorize("hasRole('USER')")
@GetMapping("/users/{id}/profile")
public UserProfile getProfile(@PathVariable Long id) {
    return userService.getProfile(id);
}

Bu xato bo‘lishi mumkin. Chunki har qanday user boshqa user ID’sini berib ko‘rishi mumkin.

To‘g‘ri:

@GetMapping("/me/profile")
public UserProfile getMyProfile(Authentication authentication) {
    return userService.getProfileByUsername(authentication.getName());
}

Yoki object-level check:

@PreAuthorize("@userSecurity.isOwner(#id, authentication)")
@GetMapping("/users/{id}/profile")
public UserProfile getProfile(@PathVariable Long id) {
    return userService.getProfile(id);
}

24. Audit logging

Security’da ayrim actionlar log qilinishi kerak:

• login success/failure;

• password reset;

• role changed;

• payment action;

• admin action;

• token revoke;

• suspicious activity.

Lekin sensitive data yozilmaydi:

Yomon:

User password changed from 123456 to qwerty

To‘g‘ri:

User 123 password changed by admin 7 at 2026-05-20T10:00:00Z

25. Refresh token xavfsizligi

Access token qisqa yashaydi. Refresh token yangi access token olish uchun ishlatiladi.

Risk:

Refresh token o‘g‘irlansa, attacker uzoq vaqt kira oladi.

Himoya:

• refresh token rotation;

• reuse detection;

• secure storage;

• HttpOnly Secure cookie;

• device/session tracking;

• revoke imkoniyati;

• expiration;

• suspicious login detection.

26. Rate limiting va brute force protection

Login endpoint himoyasiz bo‘lsa, brute force bo‘lishi mumkin.

Kerak:

IP bo‘yicha limit
username bo‘yicha limit
captcha yoki temporary lock
failed login count
alert

Masalan:

5 failed login / 5 minutes → temporary block

Lekin ehtiyot bo‘lish kerak: attacker boshqa odam username’ini lock qilib qo‘yishi ham mumkin. Shuning uchun balans kerak.

27. Real production security flow

Tasavvur qiling ecommerce backend:

Frontend
 ↓
Keycloak/Auth Server
 ↓
Backend API
 ↓
Order DB

Flow:

1. User login qiladi
2. Auth Server JWT access token beradi
3. Frontend API’ga Bearer token yuboradi
4. Backend JWT signature tekshiradi
5. Backend role/scope tekshiradi
6. Backend object ownership tekshiradi
7. Request bajariladi
8. Audit log yoziladi

Order endpoint:

@PreAuthorize("hasAuthority('SCOPE_orders:read')")
@GetMapping("/orders/{id}")
public OrderDto getOrder(@PathVariable Long id,
                         Authentication authentication) {
    return orderService.getOrderForCurrentUser(id, authentication.getName());
}

Service:

public OrderDto getOrderForCurrentUser(Long orderId, String username) {
    Order order = orderRepository.findByIdAndUsername(orderId, username)
            .orElseThrow(() -> new AccessDeniedException("Access denied"));

    return mapper.toDto(order);
}

Bu yerda ikkita himoya bor:

Scope check
Object ownership check

28. Senior darajadagi eng ko‘p xatolar

Xato 1: Faqat endpoint role bilan cheklash

Role bor, lekin user boshqa userning data’sini ko‘ra oladi.

Xato 2: JWT payloadga ishonib ketish

JWT decode qilingan, lekin signature tekshirilmagan.

Xato 3: Tokenni logga yozish

Log serverga ko‘p odam kira oladi. Token logda bo‘lsa — account hijack bo‘lishi mumkin.

Xato 4: Secrets .env yoki application.yml bilan Git’ga tushib ketishi

Bu real production incidentga olib keladi.

Xato 5: CORS * va credentials birga ishlatish

Bu xavfli sozlama.

Xato 6: Actuator endpointlarni ochiq qoldirish

/actuator/env, /actuator/heapdump, /actuator/threaddump kabi endpointlar juda sensitive.

Xato 7: Parolni encryption bilan saqlash

Parol encryption qilinmaydi. Parol hash qilinadi.

29. Senior interview savollari

Authentication / Authorization

• Authentication va authorization farqi nima?

• Role va permission farqi nima?

• Object-level authorization nima?

• Session va JWT farqi nima?

OAuth2 / OIDC

• OAuth2 nima?

• OIDC OAuth2’dan nimasi bilan farq qiladi?

• Access token va ID token farqi nima?

• Authorization server va resource server nima?

JWT

• JWT ichida nimalar bor?

• JWT encryptedmi?

• HS256 va RS256 farqi?

• exp, iss, aud nima?

• Token revoke qilish muammosi nimada?

Spring Security

• SecurityFilterChain nima?

• hasRole va hasAuthority farqi?

• CSRF qachon kerak?

• CORS security emasmi yoki browser policy’mi?

• Resource Server qanday ishlaydi?

OWASP

• SQL injectiondan qanday himoyalanasiz?

• Broken access control misoli?

• Secretlarni qayerda saqlaysiz?

• Dependency vulnerability qanday tekshiriladi?

30. Amaliy topshiriqlar

Topshiriq 1: JWT Resource Server

Spring Boot app yarating:

GET /public
GET /user
GET /admin

Talab:

/public → ochiq
/user → authenticated
/admin → ROLE_ADMIN

JWT bilan tekshiring.

Topshiriq 2: Object-level authorization

Endpoint:

GET /orders/{id}

Shart:

User faqat o‘z orderini ko‘ra olsin.
Admin hammasini ko‘ra olsin.

Topshiriq 3: Password hashing

Register/login yozing:

POST /auth/register
POST /auth/login

Talab:

Password BCrypt bilan hash qilinsin.
Plain password DBga tushmasin.

Topshiriq 4: Secrets

application.ymldagi DB parolni environment variable’ga ko‘chiring:

spring:
  datasource:
    password: ${DB_PASSWORD}

31. Qisqa xulosa

Security Java developer uchun majburiy mavzu.

Asosiy fikrlar:

Authentication — user kim?
Authorization — user nima qila oladi?
OAuth2 — ruxsat berish frameworki
OIDC — login/identity layer
JWT — token formati
JWT payload maxfiy emas
Password hash qilinadi, encrypt qilinmaydi
CSRF cookie auth’da muhim
CORS security devor emas, browser policy
Object-level authorization shart
Secrets code ichida bo‘lmasligi kerak
OWASP Top 10 real kodda tekshirilishi kerak

Eng muhim qoida:

Security keyin qo‘shiladigan bezak emas. U arxitektura, kod, config, deployment va monitoringning bir qismi.